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ABSTRACT 



The Computer Aided Prototyping System (CAPS) is used to 
develop executable prototypes of large embedded software 
systems with hard real-time requirements. The system is 
based upon the Prototype system Description Language (PSDL) 
and a set of integrated software development tools. A 
graphical tool is needed to decompose the PSDL composite 
operator into a network which shows its component parts and 
their communication paths. The graphical description is part 
of the specification of the intended system's components. 

This thesis explores the requirements of such an editor 
and demonstrates that it can be developed. It shows that the 
editor can effectively be used to decompose operators and 
that it can produce an equivalent textual representation in 
PSDL. 
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I . INTRODUCTION 

A. RAPID PROTOTYPING 

A need to improve the productivity of software 
development and the reliability of developed programs has 
resulted in research aimed at developing a system which 
allows a designer to rapidly generate prototypes of large 
real-time software systems. This system is based on 
replacing the traditional software life cycle with a two 
phase cycle consisting of rapid prototyping and automatic 
program generation. [Ref. 1] 

The process of designing a large real-time software 
system is long and labor intensive if it is feasible at all. 
Determining whether a system is feasible is often something 
which must be checked and rechecked as the design of a system 
progresses [Ref. 2]. Determining that a very large system is 
unfeasible after the entire system has been developed results 
in a tremendous loss of time and money. A computer-aided 
prototyping system (CAPS) to solve this problem is being 
studied. The rapid prototyping technique provides the 
designer with a means of writing specifications, based on 
user requirements, for components of the system being 
designed and then using reusable software components which 
match the specifications to build a prototype of the intended 
system. This prototype can then be tested to see if the 
design meets the user's needs or whether the user's 
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requirements are even feasible [Ref. 3]. The result is a 
much more timely and cost effective answer to the questions 
of feasibility and whether the design meets the 
specifications . 

B. CAPS OVERVIEW 

The CAPS prototyping environment is comprised of a 
specification language and a set of integrated prototype 
development tools. The Prototype System Description Language 
( PSDL ) is used to describe connections between components of 
the system being prototyped and to specify the behavior of 
the reusable components used in constructing the prototype. 
PSDL provides the designer with a means of creating and 
assembling abstractions of the components of the system being 
designed. The prototype development tools in CAPS include a 
user interface with sequence control function, syntax 
directed editor, graphical editor, design database, database 
of reusable software components, rewrite system and an 
execution support system. With these tools and the PSDL 
language the designer can develop an executable prototype of 
the system he is designing. This prototype will not actually 
be the intended system, but rather will be a partial 
representation of the system which can be used to analyze 
various aspects of the design. Since the prototype design is 
based on system requirements, it can be used to demonstrate 
their adequacy. Adjustments to the prototype can be made 
based on customer feedback. It can also be used to validate 
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attributes, timing constraints, I/O formats and module 
interfaces . 

C. GRAPHICAL EDITOR 

In order to construct a prototype of a large real-time 
software system, the designer needs tools which help him 
specify and decompose the system. In the CAPS system, a 
syntax directed editor is used to enter the specifications of 
the components of the system being designed. Based on this 
specification, CAPS tries to find a reusable module which 
matches (or nearly matches) the specification. If the search 
is unsuccessful, a method of decomposing the component is 
needed. The tool discussed in this paper is a graphical 
editor which the designer can use to decompose components of 
the system being designed into their subcomponents. This 
tool provides the user with a visual representation of the 
component decomposition and an equivalent PSDL representation 
which is used by CAPS to aid in the construction of the 
prototype. [Ref. 3] 

Chapter 2 of this paper discusses the CAPS environment in 
terms of the individual tools used for prototype development 
and their functional connection to the graphical editor. 
Chapter 3 provides a detailed description of how the 
graphical editor tool is used for both initial system 
decomposition and for editing an existing prototype. It also 
discusses critical issues involved in the decomposition 
process. The fourth chapter provides a detailed description 
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of the design of the graphical editor. Chapter 5 contains 
the conclusions and discusses possible follow on research. 
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II. THE CAPS ENVIRONMENT 



A. THE PROTOTYPING LANGUAGE 
1. PSDL Background 

The high level programming language Ada has several 
features which support the development of reusable modules. 
These features include information hiding, data abstraction, 
and generic packages, among others [Ref. 4]. 

PSDL is a prototyping language designed specifically 
for describing real-time software systems. It supports the 
rapid prototyping concept which is based on abstractions and 
piecing together of reusable components. There is a high 
degree of compatibility between Ada and PSDL, because of 
their similar features and the similar philosophies of large 
system design upon which they are based. In fact, the 
execution support system of CAPS which produces an Ada 
representation of the design is itself written in Ada. 

A prototype developed using CAPS is an executable 
modularized skeleton of the intended system which is used to 
validate the critical aspects of the system. PSDL is used to 
describe the behavior of components and their 
interconnections. Its design was motivated by the need for 
several capabilities including: 

1) support of modularized design with explicit module 
interconnection . 

2) an executable prototype. 
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3 ) 



the ability to decompose large complex systems in a 
simple way. 

4) a common notation for specification and design. 

5) a way to specify reusable module retrieval. 

6) both formal and informal methods of specification so 

that the designer could choose the method most 

appropriate . 

7) support for data abstraction, functional abstraction 
and control abstraction. 

8) a set of built in abstract types for use in 
constructing real-time systems. 

Since no existing language satisfied all of these 

requirements, PSDL was developed. [Ref. 5] 

2. PSDL Constructs 

PSDL is designed to provide the designer with a means 
of creating a model of a real-time system. With PSDL, the 
designer can hierarchically decompose systems based on data 
flow and control flow. PSDL provides mechanisms for creating 
abstractions for operators, data and control, 
a. PSDL Model 

The mathematical model behind PSDL is an 
augmented graph 

G = (V, E, T( v ) , C ( v ) ) 

where v is the set of vertices, E is the set of edges, T(v) 
is the maximum execution time associated with each vertex v, 
and C(v) is the set of control constraints associated with 
each vertex v. The vertices represent operators and the 

edges represent data streams. The first three components of 
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this model are represented by the data flow diagram which the 
designer develops when he is decomposing an operator with the 
graphical editor. [Ref. 5] 

(1) Operators. Operators are used to represent 
the components of the prototype. They can be used to 
represent functions or state machines. Communication between 
operators is carried out via data streams. These data 
streams carry values of a fixed abstract data type or values 
of the PSDL built in type EXCEPTION. An operator can be 
either data driven or periodic. Periodic operators fire at 
some internal whereas data driven operators fire in response 
to some stimulus from an input. When an operator fires, two 
things occur. First, it reads one data object from each of 
its input streams. It then writes at most one data object on 
each of its output streams. When a function operator fires, 
output objects are produced whose values depend upon the 
current set of input values. State machines produce outputs 
which depend upon the current set of inputs and the current 
values of their internal state variables. Operators can also 
be characterized as being either atomic or composite. If an 
operator cannot be further decomposed into more detailed 
parts, it is atomic. A composite operator can be further 
decomposed into data and control flow networks of lower level 
operators. A composite operator whose decomposition contains 
a cycle is a state machine. [Ref. 5] 
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(2) Data Streams. Data streams are the 
communication links between two operators and as such carry a 
sequence of data values. The data streams will be one of two 
types. The first type is called a DATA FLOW STREAM and is 
used to represent a FIFO queue. This type data stream 
guarantees that none of the values it carries will be lost or 
replicated. It also restricts the relative firing rates of 
the two associated operators. Data flow streams are used 
where each data value is unique and must be acted on exactly 
one time. The second type of data stream is called a SAMPLED 
STREAM. This type of data stream makes no guarantees as to 
whether its values will be lost. It is a cell capable of 
carrying just one value which is updated whenever the 
producer operator generates a new value. It can deliver the 
same value more than once if requested and will discard an 
unused value when a new one is generated. Sampled streams 
are used to simulate continuous streams of information where 
only the most recent values are meaningful. Whether a data 
stream represents a data flow stream or sampled stream is 
determined by the consumer operator's activation conditions. 
[Ref. 5] 

(3) Exceptions. PSDL has a built in abstract 
data type called EXCEPTION. Values of this type are 
transmitted along data streams like values of a normal type. 
The exception type has operations which create named 
exceptions, detect whether the value is a particular named 
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exception or detect whether the value is of a type other than 
exception. [Ref. 5] 

b. Abstractions 

PSDL provides the designer with operator, data 
and control abstractions as a means of controlling the 
complexity of his design. 

(1) Operator Abstraction. Operators consist of 
a specification and an implementation. The specification 
contains the form of the interface, timing constraints and a 
formal and informal description of the operator's observable 
behavior. The implementation part determines whether the 
operator is atomic or composite. An atomic operator has a 
keyword ADA, which specifies Ada as the implementation 
language. This is followed by the implementation module for 
the operator which is the result of a successful retrieval of 
a reusable software component, or the writing of the Ada 
component. An operator which can be further decomposed into 
component operators is called a composite operator. Its 
implementation will be a series of PSDL statements which show 
the relationships between its components. [Ref. 5] 

There are two kinds of operator 
abstractions: functional abstraction and state machine 
abstraction. The difference between the two is that a state 
machine abstraction has a state declaration in its 
specification part, whereas a functional abstraction does 
not. [Ref. 5] 
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(2) Data Abstraction. Data abstraction is used 
to decouple a data type's behavior from its representation. 
It allows interfaces to be described independent of their 
data representation. Therefore, interfaces in the prototype 
are the same as those in the system being designed. This 
simplifies system validation and enables the structure of the 
prototype to be used in the intended system. [Ref. 5] 

All PSDL data types are immutable, meaning 
that they cannot communicate via side effects. The data 
types include: those Ada built in types which are immutable, 

user defined abstract data types, TIME, EXCEPTION and the 
types which can be built using the PSDL type constructors 
listed in Table 1. [Ref. 5] 

TABLE 1. PSDL TYPE CONSTRUCTORS [Ref. 5] 

set[item: type] 

sequence [ item : type ] 

map [ from : type , to : type ] 

tuple [tag_l : T_1 , . . . , tag_n:T_n] 

one_of [ tag_l : T_1 , ... , tag_n : t_n ] 

relation [tag_l :T_1 , . . . , tag_n:T_n] 

(3) Control Abstraction. Control abstraction in 
PSDL is represented by the enhanced data flow diagrams 
developed with the graphical editor together with a set of 
control constraints. The data flow relationships of the 
enhanced data flow diagram determine the order of execution 
of the operators. [Ref. 5] 
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c. Control Constraints 



An operator's control is specified by its control 
constraints. The aspects of the operator which are specified 
by its control constraints are: whether it is PERIODIC or 
SPORADIC, its triggering condition and its output guards. If 
an output guard is not satisfied it prevents outputs from 
being placed on the output streams. Periodic operators are 
triggered by the static scheduler at some specified interval 
whereas sporadic operators trigger on the arrival of new 
data . 

An operator's triggering condition can be either 
BY ALL or BY SOME. If the triggering condition is BY ALL, 
the operator will fire only when it has new values on all of 
its inputs. This ensures that its output is based on the 
presence of fresh data on all of its inputs. The BY ALL 
triggering condition is used to synchronize processing when 
there are inputs from many data streams. If the BY SOME 
triggering condition is used, the operator will fire when any 
of its inputs get a new value. This guarantees that the 
operator's output is based upon the most recent input values. 
[Ref. 5 J 

All operators are required to have a firing 
period or a data trigger and may have both. Periodic 
operators which have data triggers are conditionally executed 
with the data trigger serving as the input guard. 
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A timer is a abstract state machine used in 
keeping track of time between events, or the amount of time 
spent in a state. It is important that a system for modeling 
real-time systems has a facility for expressing event timing. 
There are four operations which can be performed on timers: 
START, STOP, READ and RESET. These are analogous to the 
operations performed on a stop watch. [Ref. 5] 

Two kinds of conditionals are available in PSDL: 
conditional execution of an operator and conditional 
transmission of output. 

A triggering condition acts as a guard for an 
operator. If an operator's triggering condition is true, it 
reads its inputs and fires. If the triggering condition is 
not true, the operator will read its input data streams but 
will not fire. The triggering conditions for periodic 
operators are tested at an interval specified by its period. 
[Ref. 5] 

An output guard gives the effect of passing an 
unconditional output through a filtering operator. If the 
triggering condition is satisfied, the filtering operator 
fires and passes its input values on. In the event that the 
triggering condition is not met, the filter removes the value 
from its input stream without effecting its output stream. 
[Ref. 5] 
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d. Timing Constraints 

Since timing is a critical issue in real-time 
systems, any language used to specify these systems must have 
provisions for expressing the timing aspects of a system's 
operation . 

There are three basic timing constraints in PSDL: 
MAXIMUM EXECUTION TIME (MET), MAXIMUM RESPONSE TIME ( MRT ) and 
MINIMUM CALLING PERIOD (MCP). An operator's MET is the 
maximum amount of time it takes to execute from the instant 
it starts to the instant it completes. A sporadic operator's 
MRT is the maximum amount of time between the arrival of new 
data and the time the last value is put into an output stream 
in response to the new input value's arrival. In the case of 
triggered BY ALL, "new data" means the last new input value 
in the ALL list. For triggered BY SOME, "new data" means any 
new input value in the SOME list. The MRT for a periodic 
operator is the maximum amount of time from the beginning of 
its firing period to the time when its last value is put onto 
an output stream during that period. [Ref. 5] 

The MCP applies only to sporadic operators. It 
specifies the least amount of time between the arrivals of 
sets of input values. Every sporadic operator with an MRT 
must have an MCP. The MCP must be greater than or equal to 
the MRT for state machine operators in either single or 
multi-processor cases and for function operators in the 
single processor case only. 
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More complex timing constraints can be given by 
using event controlled timers, triggering conditions and 
output conditions . [Ref . 5] 

e. Hierarchical Constraints 

Any PSDL operators which are not atomic must be 
decomposed into their component operators. This 
decomposition is done hierarchically from top down. There 
are several constraints associated with the hierarchical 
structure. Inputs and outputs which occur at one level of 
decomposition must occur at some point in each subsequent 
level of decomposition. Data streams which are introduced by 
decomposing an operator into a network of operators must also 
appear in each further level of decomposition as inputs and 
outputs. METs and MRTs within a decomposition can be no 
longer than those of their associated composite operator. An 
operator's decomposition inherits its period, MCP, and the 
types of its input and output data streams. A composite 
operator inherits the exceptions produced by its component 
operators . [Ref . 5 ] 

B. PROTOTYPE DEVELOPMENT TOOLS 

The development of a prototype with CAPS progresses in 
much the same way as a programmer develops a program. The 
primary difference being that with CAPS the user is provided 
with a means of designing at a level of abstraction above 
that of even a high level programming language. Another 
difference is that with CAPS the design is driven directly by 
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the user's specifications which ensure that the end product 
truly will meet the requirements of the intended system. 

A typical programming environment for creating programs 
provides an integrated set of tools which support program 
development and testing. All have a user interface of some 
type (be it friendly or unfriendly), some form of textual or 
graphical editor for creating and modifying the program, some 
means of storing the program, and a way of testing and 
debugging the program. Program development progresses as a 
cycle of entering a program, repeatedly testing, debugging 
and modifying it until it runs as desired. 

The CAPS prototyping environment has tools which perform 
tasks analogous to those of programming environments. One of 
the primary differences between CAPS and a programming 
environment is that a CAPS prototype is based directly upon 
system requirements. Another difference is that CAPS, unlike 
most other environments, is heavily dependent upon the 
existence of reusable ADA software components. CAPS has 
tools which support storage of reusable software components, 
formally describing reusable software components, initially 
developing the prototype and support for the test, debug and 
modify phase of development. 

1. System Control 

CAPS is controlled by the sequence control function 
of the user interface subsystem [Ref. 6]. This portion of 
the system provides the user with an easy method of invoking 
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tools, hides the details of tool interaction and prevents the 
user from making system operation errors. 

2. Prototype Creation and Modification 

Two tools are available which support creation and 
modification of the intended prototype. The syntax directed 
editor provides the designer with a means of entering PSDL 
specifications and control constraints for the various system 
components. The graphical editor provides a means of 
decomposing composite operators into networks of component 
operators connected by data streams. When the designer 
signals to the graphical editor that the decomposition is 
complete, the editor scans the operators and data streams and 
creates PSDL link statements [Ref. 7] which are textual 
representations of the graphical objects. 

The syntax directed editor and graphical editor are 
used together in an iterative fashion to enter the 
specifications of the components of the system, specify their 
connections and timing relationships and to ultimately 
decompose the entire system into its atomic parts. Each 
atomic operator will either be implemented by an existing 
reusable Ada module or must be coded. 

As the decomposition process takes place, a prototype 
of the intended system will be assembled in the design 
database. Once the entire specification and decomposition 
process has been completed, the design data base will contain 
an abstract tree representation of the entire system. The 



16 



central nodes of the tree will contain the information for 
the composite operators and the leaves will be the atomic 
operators. The design database has facilities for retrieval, 
addition and deletion of the PSDL objects that it stores. 

3. Prototype Testing Tools 

The execution support system (ESS) of CAPS is used to 
test the designer's prototype, which is stored in the design 
database, discover errors and make reports to the user so 
that he can make the necessary design modifications. The 
components of the ESS are: a TRANSLATOR, a STATIC SCHEDULER 
and a DYNAMIC SCHEDULER. 

The translator's function is to convert each PSDL 
specification into an executable Ada module [Ref. 8]. The 
static scheduler looks for operators which have timing 
constraints which must be met. It then creates a schedule 
which specifies the order in which the time critical 
operators must execute. The translated modules and the 
static schedule are passed on to the dynamic scheduler which 
executes the translated modules in the order specified by the 
static schedule. If a time critical module runs in less time 
than was allocated by the static scheduler, the dynamic 
scheduler will schedule non-time critical operators (modules) 
to run during the time gap. The dynamic scheduler also 
provides feedback to the user interface based on run time 
exceptions generated by the translator or static scheduler. 
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4. Reusable Component Support Tools 

The rewrite subsystem of CAPS is used to normalize 
the specification of Ada modules. The reusable software 
component database is used to store reusable Ada components. 
It has facilities for storing, searching for and retrieving 
these reusable components based on their normalized 
specification . 

C. SYSTEM OPERATION 

Development of a prototype using CAPS progresses in two 
distinct phases: 

1) Initial System Design 

2) Test and Modify 

1. Initial system Design 

During this stage of development of the prototype, 
the editors are used to construct an abstract tree 
representation of the prototype. 

Initially, the designer uses the syntax directed 
editor to enter the specification part of the highest level 
operator. The sequence control function then initiates a 
search of the software database for a component which matches 
the normalized description of this specification. This 
search will yield one of three possible results. The first 
possibility, which will become more likely as the software 
database matures, would be that a reusable component is found 
which matches the specification. In this case, the reusable 
component is retrieved and is attached to the specification 
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as the implementation part. The initial design stage would 
be complete at this stage. 

The second possibility would be that a reusable 
module could not be found, but the operator is atomic. 
Atomic operators are those for which no further decomposition 
is necessary. In this case, the implementation part simply 
contains the keyword ADA signifying that the implementation 
must be coded. Again, the design stage would be complete. 

The third and most likely possibility, especially at 
high levels in the design, is that a reusable component will 
not be found and the operator is composite. In this case, 
the graphical editor must be used to decompose the operator 
into a network of operators and data streams at the next 
level of detail. Once the decomposition is complete at this 
level, the graphical editor will transform the graph into 
PSDL link statements. These link statements become part of 
the implementation part of the operator's specification. 
Next, the syntax directed editor is used to enter any control 
constraints which are needed to complete the specification of 
the operator's behavior. Once the entire specification is 
complete, the sequence control function notifies the design 
database of the existence of the new operators so that it can 
allocate their storage. Finally, the PSDL specification file 
for the decomposed operator is stored in the design database 
as an object. The graphical information necessary to 
reconstruct the drawing is also stored with the object. 
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The process described is repeated until the intended 
prototype is completely comprised of atomic operators which 
are either reusable components or modules which must be 
coded. 

2. Test and Modify Phase 

Once the initial prototype design has been completed, 
it is necessary to test it and make necessary modifications. 
Before the testing can occur, the sequence control function 
must collect the specifications together and pass them to the 
ESS [Ref. 6]. 

a. Testing the Design 

Before the prototype design can actually be 
executed, the PSDL specifications must be translated into Ada 
and the order of their execution must be determined. The 
translator scans through the PSDL specification file and 
translates each operator's specification part, implementation 
part and constraint part into an equivalent Ada module [Ref. 
9], If translation errors are found, translation exceptions 
will be raised, otherwise the translated modules are passed 
to the dynamic scheduler for eventual execution. 

In order to actually execute the Ada modules, a 
schedule is required which will determine the order that the 
time critical modules will execute. The static schedule, in 
simple terms, is a series of calls to the translated modules 
which have time constraints [Ref. 10]. If scheduling errors 
occur then scheduling exceptions are raised. If no 
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scheduling errors occur, the schedule is passed on to the 
dynamic scheduler. 



The dynamic scheduler actually performs the run 
time testing of the prototype. It uses the static schedule 
to call the translated modules. If one of the time critical 
modules does not use up its allocated time slot, the dynamic 
scheduler schedules non-time critical modules to run. If run 
time errors occur, run time exceptions are raised. 
Otherwise, the prototype is feasible and is known to meet the 
specifications . 

b. Modifying the Design 

Exceptions raised during translation, creation of 
the static schedule or during execution signal that the 
prototype design must be modified. The sequence control 
function of the user interface responds by invoking either 
the syntax-directed editor or graphical editor, as 
appropriate, so that the necessary corrections can be made to 
the design. 
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III. USING THE GRAPHICAL EDITOR 



A. PURPOSE 

The graphical editor is one of the designer's primary 
tools for designing the intended system. It provides him 
with a simple way of expressing what the parts of the system 
will be and how those parts interact in terms of time 
relationships and communications. Once the highest level 
operator has been entered, the graphical editor becomes the 
initial point of entry for all lower level operator names, 
data stream names and maximum execution times. 

In order for the graphical editor to provide the designer 
with the maximum expressive power, it must support any type 
of graph which could possibly be used to represent a system's 
components and their associated data streams. It must then 
be able to convert the graphical representation of the graph 
into a textual form which captures the meaning intended by 
the picture. The PSDL link statements are used to express 
what data stream is used to communicate between two 
operators. Figure 1 . ( a ) shows a PSDL specification of an 
operator named SPEED_CONTROL_SYSTEM . The specification part 
shows that the operator has inputs SHAFT_RPM and DESIRED_RPM 
and an output ACCEL_CONTROL . The two exceptions 
PRESENT_SPEED_TOO_SLOW and DESIRED_SPEED_TOO_SLOW are Special 
conditions which will be handled external to the operator 
being decomposed. The maximum execution time shows that the 
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SPECIFICATION 

OPERATOR SPEED_CONTROL_SYSTEM 
SPECIFICATION 

INPUTS SHAFT_RPM : real, 

DESIRED_MPH : real 

OUTPUTS ACCEL_CONTROL: controlling_action 

EXCEPTIONS PRESENT_SPEED_TOO_SLOW , 
DESIRED_SPEED_TOO_SLOW 

MAXIMUM EXECUTION TIME 2s 

DESCRIPTION 

{ Returns command to accelerate, decel- 
erate or hold present setting based on 
a comparison of the present speed with 
the desired speed. If the present speed 
or desired speed are below 30 mph 
exceptions are produced. 

> 

END 



(a) Operator Specification 




(b) Operator Decomposition 



DESIRED_MPH. EXTERNAL-- >CONV_MPH_TO_RPM 
DESIRED_RPM.CONV_MPH_TO_RPM: 500MS-- >COMPUTE_RPM_DIFF 
SHAFT_RPM . EXTERNAL-- >COMPUTE_RPM_DIFF 
RPM_DIFF . COMPUTE_RPM_DIFF : 500MS-->GENERATE_RESPONSE 
ACCEL CONTROL. GENERATE RESPONSE : 1S-->EXTERNAL 



(c) PSDL Link Statements 



Figure 1 Decomposition of an Operator 
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operator must execute in 2 seconds. Therefore, no path in 
the operator's decomposition can have a total time greater 
than 2 seconds. Figure l.(b) shows a graph of the operator's 
decomposition. It shows that SPEED_CONTROL_SYSTEM was 
decomposed into three operators: CONV_MPH_TO_RPM, 
COMPUTE_RPM_DIFF and GENERATE_RESPONSE . Each operator's MET 
is shown above it. DESIRED_MPH and SHAFT_RPM are shown as 
inputs to CONV_MPH_TO_RPM and COMPUTE_RPM_DIFF respectively. 
ACCEL_CONTROL is shown as an output from GENERATE_RESPONSE . 
The lines labeled DESIRED_RPM and RPM_DIFF are data streams. 
After the decomposition has been completed, the syntax 
directed editor will be used to enter the control constraint 
part of the PSDL specification. This is used to more 
precisely specify the operator's behavior. 

Figure l.(c) shows the PSDL link statements which the 
graphical editor would produce for the graph shown in Figure 
l.(b). PSDL link statements have the syntactic form 

data stream . source [ : MET ] --> destination 

where : MET is optional. The maximum execution time must be 
an integer value and have units as shown in Table 2. 



TABLE 2 PSDL TIMING UNITS 



UNITS 


MEANING 


m 


minutes 


s 


seconds 


ms 


milliseconds 
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The source operator name and destination operator name is 
"EXTERNAL" for data streams which come from or go to an 
operator external to the current diagram. 

In order for the designer to be able to alter an existing 
graph in response to errors found during testing, the 
graphical editor must have the capability to reload and 
redraw a previously decomposed operator's diagram. After 
this has been done, the designer can edit the diagram by 
adding and deleting objects from it. 

B. DECOMPOSING AN OPERATOR 

When it has been determined that an operator must be 
decomposed into its components, the user will start the 
graphical editor. In order to reduce the amount of 
information that the designer must memorize, the following 
information must be retrieved from the operator's 
specification part and be made available: 

1) OPERATOR'S NAME 

2) LIST OF INPUTS TO THE OPERATOR 

3) LIST OF OUTPUTS FROM THE OPERATOR 

4) LIST OF STATES 

5) THE OPERATOR'S MAXIMUM EXECUTION TIME 

Making this information available to the designer helps 
to ensure correctness between levels of the graph, because 
once a data stream is identified on one level, it will exist 
on all subsequent levels of that operator's decomposition. 
Once a MET is assigned, each level of the operator's subtree 
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must execute in that same amount time or less. This is where 
the hierarchical constraints of PSDL are realized. 

1. Using the Graphical Editor 

The graphical editor runs in a window environment. 
It has five editing modes which allow the user to draw five 
types of objects: operators, external inputs, external 

outputs, data streams and self loops (PSDL states). The 
default editing mode is DRAW OPERATOR. In this mode the 
designer can draw expandable bubbles with names and time 
constraints (See Figure 2. (a)). The DRAW DATA STREAM mode 
allows lines to be drawn between two previously drawn 
operators (See Figure 2 . ( b ) ) . Input lines coming from some 
source external to the operator being decomposed can be drawn 
in the DRAW INPUT mode (See Figure 2 . ( c ) ) . Output lines are 
drawn in the DRAW OUTPUT mode. These lines designate data 
streams which leave the operator being decomposed (See Figure 
2 . ( d) ) . The DRAW SELF LOOP mode allows the designer to draw 
state variables (See Figure 2 . ( e ) ) . Syntax checks are 

done to ensure that the graphical objects are drawn in a 
manner which will ensure that the resulting PSDL link 
statements will be correctly formed. In addition to syntax 
checking the graphical editor also does some semantic 
checking. These checks try to ensure that what the designer 
draws conveys its intended meaning and also that the 
resulting link statements convey the same meaning as the 
diagram . 
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10m 




(b) datastream 



input_l 

input_2 



(c) inputs 
17s 





state_name 




(e) state 

Figure 2 Graphical Objects Used to 
Decompose Operators 
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C. CORRECTNESS AND CONSISTENCY 



1. syntactic Correctness 



Drawing 


graphical 


representations 


of networks 


of 


operators 


is a 


high level 


form of visual 


programming . 


As 


with any 


language, this pictorial language 


has an associated 


syntax . 


The 


graphical 


editor provides 


a medium 


for 



constructing these visual programs. It will only accept 
symbols which it knows are in the visual language that it 
understands. User input which fails to fit the syntax of the 
pictorial language is ignored. 

The operator decomposition language consists of 
expandable bubbles and arrows. The bubbles which are used to 
represent operators can be drawn in any size, but must not 
overlap other operators. Allowing bubbles to overlap would 
cause the problem of ambiguous "picking" when connecting or 
deleting operators. 

Arrows represent data streams. Since an arrow can 
have four different meanings in the language, its syntax is 
more complex than operators . Arrows which represent inputs 
to the decomposition diagram, must start on a point in the 
drawing space not occupied by an operator and must terminate 
on an operator. Arrows representing output lines must 
originate on an operator and terminate on a spot in the 
drawing area which is not occupied by an operator. Data 
streams are represented by arrows which start on one operator 
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and terminate on another. PSDL state variables are drawn 
using the self loop mode of the editor. A self loop's arrow 
must start and terminate on the same operator. Lines which 
are not syntactically correct are rejected by the editor and 
immediately erased. 

A correctly formed PSDL operator decomposition 
diagram has all of its component objects named. Therefore, 
the graphical editor will not allow an object to be drawn 
which has not been named. In the case of operators, there 
must also be a MET entered. All names used in the 
decomposition will eventually be used as either module names 
or names of abstract data types (ADT) in the intended 
prototype. Since these modules and ADTs will be implemented 
in Ada, the graphical editor requires that all object names 
are syntactically correct Ada identifiers (See Figure 3). 
The graphical editor also checks that an operator's MET is 
syntactically correct (See Figure 4). 



identifier ::= letter{ [underline ] letter_or_digit } 

letter_or_digit ::= letter | digit 

letter := upper_case_letters | lower_case_letters 



Figure 3 Backus-Naur Form of Ada an Identifier [Ref. 11] 



MET ::= <digit_string> <time_unit> 
digit_string ::= digit | digit_string 
time_unit ::= m | s | ms 



Figure 4 Backus-Naur Form of Maximum Execution Time 
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2. Semantic Correctness 



The same mechanisms used to do syntactic checking of 
a decomposition also provide the semantic checking. The 
editing mode tells the editor what the designer's drawing 
actions should mean. If something is drawn which does not 
fit the syntactic criteria for the object indicated by the 
mode, the system rejects it. This ensures that the 
decomposition will have the designer's intended meaning. 
Without this comparison of editing mode and specific object 
criteria the graphical editor would have no way of ensuring 
that the designer's actions actually conveyed their intended 
result . 

3. View Consistency 

CAPS is faced with a problem common to many software 
development environments which represent objects in multiple 
ways. That is, how to ensure that all other views of an 
entity are appropriately changed when one of them is 
altered. [Ref. 12] . 

A view is a way of representing an object within a 
system. Each decomposed operator has a graphical 
representation which is used to reconstruct the picture and a 
textual PSDL specification representation. After an operator 
is completely decomposed with the graphical editor, the 
editor automatically performs a transformation on the picture 
and produces the equivalent PSDL link statement 
representation. From this point on, the problem of 
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maintaining view consistency exists. A change in one view of 
the object should automatically result in a corresponding 
change to the object’s other view [Ref. 12]. Failure to keep 
the PSDL specification view and the graphical view consistent 
will rapidly destroy the integrity and intelligibility of the 
design. Since CAPS does not currently have a method of 
running concurrent view editors, some other method must be 
used to ensure view consistency. 

One way of ensuring view consistency is to make the 
requirement that changes to the specification must be made in 
the graphical editor instead of the syntax-directed editor if 
the change involves any of the following items: 

1 ) operator names 

2) data flow names 

3) connections between operators 

4) maximum execution times 

5) adding new objects to a decomposition 

6) deleting objects from a decomposition 

For changes involving these items, the existing decomposition 
should be reloaded into the graphical editor, the changes 
should be made as needed and new PSDL link statements and a 
new diagram file should be generated. Then the syntax 
directed editor should be used to make any further changes to 
the operator’s specification which are necessary. Changes to 
the specification which do not involve the six listed items 
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could not cause this problem and therefore do not require 
this restriction. 

4. Consistency Between Levels of Decomposition 

After an operator has been decomposed, a new node is 
created in the design database for each new component 
operator. Each input, output and state of the operator being 
decomposed must be represented as an input or output to some 
operator in its decomposition (See Figure 5). 

Ensuring consistency between hierarchical levels 
during the initial decomposition poses very little problem 
because the sequence control function creates a specification 
shell for each new operator in the decomposition [Ref. 6]. 
This shell contains a portion of each new operator's 
specification part (See Figure 6). When the graphical editor 
is used to further decompose each of these operators, the 
sequence control function should pass in the operator's name, 
its input list, output list, state list and MET. Making 
these items available will help the designer ensure that each 
input, output and state of the operator being decomposed is 
used in the decomposition. In addition, the availability of 
the MET will reduce the likelihood of a time constraint 
violation in his decomposition. 

Maintaining consistency between levels when making 
modifications is more difficult for certain types of changes. 
If an operator in any particular level is deleted, his entire 
subtree must be deleted from the design database. This is a 
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lm 




15s 




(b) 



Figure 5 Decomposition of Operator into 
Its Component Operators 
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Figure 6 



Stub Specifications Resulting 
From Operator Decomposition 
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MAXIMUM EXECUTION TIME 30s 



simple process. However, if an operator's connectivity is 
changed by deletion, addition or by redirecting of data 
streams, its entire subtree must be rechecked to ensure 
consistency. This should be done in the same top down 
fashion as decomposition, having the sequence control 
function pass in the input, output and state names for the 
appropriate operator as is done with decomposition. Also of 
value in this process is the ability to look up or down a 
level in the decomposition hierarchy. However, allowing the 
designer to randomly edit up and down between levels could 
cause inconsistencies between the pictorial view and the 
specification. The problem being that as the diagrams are 
changed, the specifications would remain unchanged. With a 
sufficient number of changes, it could become very difficult 
for the designer to make the textual and pictorial views 
match . 
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IV. DESIGN OF THE GRAPHICAL EDITOR 



A. STATIC SCHEDULER CONSIDERATION 

The static scheduler is the portion of CAPS which uses 
the decomposition information contained in the PSDL link 
statements. Therefore, it has a major impact on the design 
of the graphical editor. 

The static scheduler determines precedence relationships 
between operators by analyzing the link statements. Research 
was conducted with the intent of reducing the amount of time 
and memory required to perform the scheduling task. One 
possible solution, which was investigated, was to supply the 
scheduler with the exact source and destination of the inputs 
and outputs of the decomposition. Doing this would require 
the static scheduler to only consider the link statements of 
the composite operators which are parents of atomic 
operators. For a large system this would be a large 
reduction in the quantity of operators considered. 

This approach was determined to be unfeasible for two 



reasons . 


First, there were 


situations 


where a 


single 


data 


stream in 


a decomposition 


could 


be 


represented by 


two 


equivalent 


link statements 


that 


the 


machine 


could 


not 



determine were equivalent. Figures 7 through 10 show a 
decomposition which illustrates this problem. The circled 
pairs of link statements in Figures 7 and 8 represent the 
same connections, but due to their different names the 
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input I 



input2 



10s 




output 




input 1 .extemal->Proc_a 
input2.extemaI-->Proc_b 
ds_a.Proc_a:2s-->Proc_b 
ds_b . Proc_a : 2s— >Proc_b 



ds_e .Proc_a:2s->Proc_c 
ds_c .Proc_b :4s->Proc_c 
ds_d.Proc_b :4s— >Proc_c 
output .Proc_c: 2s->extemal 



Figure 7 Overall System Decomposed into its Component 
Operators 
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input 1 




input 1 .external ->A_a 
ds_abl .A_a: Is— >A_b 



ds_ab2.A_a: ls->A_b 
ds_acl . A_a: 1 s— >A_c 



ds_ac2.A_a: 1 s->A_c 



ds_cb.A_c: ls->A_b 



ds_a. A_b: 1 s— >Proc_b 
ds_b.A_b:ls->Proc_b 



ds_e.A_c: Is— >Proc_c 



Figure 8 Decomposition of Proc_a 
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input2 




ds_c 

ds_d 



input2.extemal— >B_a 
ds_a . Proc_a : 2s —>B _a 

ds_b.Proc_a:2s~>B_b 
ds_Babl .B_a;500ms->B_b 

ds_Bab2.B_a:500ms-->B_b 
ds_c.B_b:500ms— >Proc_c 
ds_d.B_b:500ms-->Proc_c 

Figure 9 Decomposition of Proc_b 
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500ms 




ds_ac 1 . A_a: 1 s~>A_c_a 
ds_ac2. A_a: 1 s— >A_c_b 
ds_ca_cb.A_c_a:500ms->A_c_b 
ds_cb.A_c_a: 500ms— >A_b 
ds_e.A_c_b:500ms->Proc_c 

Figure 10 Decomposition of A_c 
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machine could not possibly discover this. Second, sorting 
through all of the link statements associated with all of the 
atomic operators creates a potentially unsolvable problem. 

A tree data structure can be used to assist in the 
creation of a schedule of operators. Store the name of the 
highest level operator in the root of the tree. Then 
determine the schedule for the operators in the root 
operator's decomposition. Store the names of these operators 
as children of the root operator in the order that they must 
be scheduled. Repeat this process for all operators until a 
tree containing all of the system's operators has been 
created. When the tree has been completely built, its 
frontier will contain a linear schedule of the operators (See 
Figure 11). Since this method does not require that one 
subtree have any knowledge of connections to other subtrees, 
there is no need for explicit sources and destinations for 
external inputs and outputs. The linked storage structure 
which is assembled by the graphical editor during a given 
operator's decomposition need only provide the information 
for showing relationships between the components of that 
operator's decomposition. 

Based on these discoveries, the graphical editor was 
designed so that inputs and outputs for any decomposition 
come from and go to operators named EXTERNAL. 
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Figure 11 storage of Operator Names in Tree Structure 
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B. INTERFACE DESIGN INFLUENCES 



Four factors influenced the design of the graphical 
editor's user interface: 

1) the choice of machines on which to implement CAPS 

2) the choice of interface software support 

3) human factors issues 

4) user interface design guidelines 

1. Sun Workstation 

The Sun Workstation has many features which make it 
the machine of choice for the development and implementation 
of CAPS. The availability of a dedicated CPU in a 

multitasking environment greatly enhances the design team's 
ability to code, test and debug their software. The Sun 
workstation provides a powerful integrated programming 
environment based on the unix operating system with its 
standard utilities which include: 

1) Ada, C, Pascal and Fortran 77 compilers 

2) vi and emacs editors 

3) dbx debugger 

4 ) make 

5) revision control systems 
and numerous others [Ref. 13]. 

2. Interface Software Support 
a. Sun View 

Sun View is a window based user environment which 
supports interactive graphics-based applications. There are 
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two aspects to Sun View. First, it is a user interface which 
provides multiple overlapping windows, each of which can run 
a task independent of the other windows. Second, it is a 
general toolkit for building window-based applications. A 
set of subroutine libraries provide three levels of 
abstraction for development of program interfaces [Ref. 14]. 

The highest level of abstraction for interface 
design is provided by the SUNTOOL library. It provides the 
functions of the User Interface Management System (UIMS) and 
also the functions necessary for the interactive creation of 
window applications. [Ref. 15] 

The SUNWINDOWS library provides the middle level 
of interface abstraction. These functions are used to manage 
the hierarchy of overlapping windows. [Ref. 15] 

The lowest level of abstraction is provided by 
the PIXRECT library. This library provides the functions 
needed for low level manipulation of pixels. [Ref. 15] 

b. Interface Utilities 

Sun View provides built in user interface 
utilities. The NOTIFIER is used to capture and distribute 
events among the multiple applications which are running. A 
SELECTION SERVICE is used to manage text selections. [Ref. 
14] 

c. Interface Building Blocks 

Four types of windows are provided as building 
blocks for constructing user interfaces [Ref. 14]: 
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1) canvases provide an area on which programs can draw 

2) text subwindows are used to display textual data 

3) panels contain buttons and choice items 

4) tty subwindows provide a capability to run other 
programs 

d. The Sun View Model 

Sun View is an object-oriented system whose 
objects are assembled in such a manner as to build a user 
interface. There are six classes of objects, the most 
important of which is a window (See Figure 12). Within the 
window class are the objects subwindow and frame. The 
subwindow objects are Canvas, Panel, Text and TTY. 

Frames are window objects which themselves can be 
overlapped. They serve as a frame which surrounds a group of 
nonoverlapping subwindows, allowing them to be operated on as 
a unit. 

Frames may also contain other frames. So the 
overall structure of Sun View is a tree of windows. The root 
of the tree is the base frame. The non-leaf nodes are frames 
and the leaf nodes are subwindows [Ref. 14]. Figure 13 shows 
the tree structure of the objects which comprise the 
graphical editor. 

3. Human Factors 

Since the graphical editor is a tool designed to aid 
a human in development of a software system prototype, human 
factors must be considered in its design. 
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Figure 12 Sunview Objects [Ref. 14] 



46 




Frame 




= Subwindows 



Figure 13 Tree Structure of Objects Comprising 
the Graphical Editor 
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a. Functional Principle 

Systems with many controls can be very difficult 
to learn and use. To reduce this difficulty and also reduce 
the likelihood of errors, controls should be grouped 
according to their functionality [Ref. 16]. The graphical 
editor's controls fall into three functional groups (See 
Figure 14 ) : 

1) system control group 

2) editing mode group 

3) text input group 

b. Sequence of Use Principle 

Another way to improve the usability of a group 
of controls is to organize them in the same sequence that 
they are used. This improves the usability of a system by 
eliminating the need to jump around and therefore minimizing 
the amount of information the user must remember [Ref. 16]. 
The controls of the graphical editor are organized to be used 
in a series of top to bottom sequences. The top panel is 
used to control overall system functions: LOADING, STORING 

AND QUITTING. This panel is only used at the beginning and 
end of an editing session. The next panel down is the 
editing mode panel . It is used to switch from drawing one 
type of object to another. After the editing mode is 
changed, the user must enter a name and in the case of an 
operator, a time constraint. The input panels for these are 
therefore located immediately below the editing mode panel. 
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Figure 14 Functional Grouping of Controls 
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system control group # editing mode group + text input group 



The drawing canvas is located immediately below the input 
panels. This ordering of controls always allows, but does 
not force, the user to operate in a top to bottom circular 
fashion as follows: 

1) select mode (optional) 

2) enter and read name 

3) enter and read time constraint (if in operator mode) 

4) draw object 

5) repeat until done 

c. Human Memory Capacity 

Studies have shown that humans have the capacity 
to remember 7 ± 2 things [Ref. 16]. With this in mind, 
interface designers should keep the length of selection lists 
within this boundary if possible. The graphical editor was 
designed to meet this criteria. It consists of five basic 
parts and its longest menu has only five choices. 

4. User Interface Design Guidelines 

Reference 15 provides a list of guidelines which 
should be applied when designing a user interface. 



1) 


Be intuitive (things should work as you would expect) 


2) 


Accommodate experts and novices 
override mechanisms) 


(provide confirmation 


3) 


Allow customization 




4) 


Provide extensibility 




5) 


Use lots of feedback (show status 
clear ) 


; make error messages 


6) 


Be predictable (use a consistent, 
of basic actions in obvious ways) 


easy to remember set 
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7) Be deterministic (consider type ahead and mouse ahead 
effects ) 

8) Avoid modes (if states that persist are necessary, 
make the feedback and exit path obvious) 

9) Do not preempt the user (don't force them to respond) 

C. INPUTS AND OUTPUTS 
1 . Inputs 

The graphical editor accepts inputs from either the 
mouse or the keyboard. No restrictions are placed on the 
order that any of these inputs must occur except that a name 
must have been read before any type of object can be drawn. 
In the case of an operator a MET must also have been read. 
Figure 15 shows a black box representation of the graphical 
editor with all of its inputs and outputs. 

An operating mode select event occurs when the mouse 
pointer is placed over one of the operating mode buttons and 
the left mouse button is pushed. This type of input selects 
whether the editor should (1) load an existing diagram, (2) 
store the current diagram or (3) quit. The default mode is 
for the editor to be ready to create a new diagram. 

An editing mode select event is also a mouse input. 
This input establishes the context in which canvas events 
will be interpreted. 

To draw an object the user positions the mouse 
pointer in the canvas area, pushes the left mouse button 
down, moves it to another location and releases it. 
Releasing the left mouse button causes an end of object event 
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Figure 15 Inputs and Outputs of the 
Graphical Editor 
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which tells the editor to draw the object using the start and 
stop locations. 

To delete an object the user positions the mouse on 
the object to be deleted and initiates a right mouse button 
down event. This input will erase the object from the 
display and free up its storage. 

Textual inputs to the graphical editor are typed in 
via the keyboard. These inputs will only be accepted if the 
mouse pointer is located in one of the text panels. After 
text input has been entered, it must be validated by causing 
a read event. This is done by positioning the mouse pointer 
over the appropriate read button and pushing the left mouse 
down . 

If the graphical editor is going to be used to edit 
an existing diagram, the user interface function must 
retrieve the necessary reconstruction information from the 
design database and store the information in a file named 



graph .pic 


prior 


to invoking 


the 


editor 


[Ref. 6]. 


The 


graphical 


editor 


then reads 


in 


this 


information 


and 



reconstructs the diagram. 

2. Outputs 

The graphical editor has two kinds of outputs: 
visual and textual. If the user draws an object, it is 
displayed on the canvas so that he can see it. If a user 
generated error occurs, an error message will immediately be 
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displayed at the top of the canvas. Once the error condition 
has been corrected, the error message disappears. 

When the mouse is in a particular subwindow of the 
display, visual feedback in the form of a bold subwindow 
border, is provided. 

After a decomposition has been completed and the user 
has selected store, the editor will generate two kinds of 
textual output. The PSDL link statements will be written to 
the file graph. link. Also, the information needed to 
reconstruct the diagram will be written to the file 
graph. pic. The user interface will store this information in 
the design database [Ref. 6]. 

D. DATA STRUCTURES 

The primary storage structure for the graphical editor is 
a linked list of operators. A single structure named 
Operator_list has pointers to the head and tail elements of 
this list. Each element in the operator list is a structure 
of type Operator. The Operator structure has ten fields (See 
Figure 16 ) . 

The name field is a pointer to a name structure which is 
comprised of an 40 character array and a field specifying the 
length of the name. The optype field is used to signify 
whether the structure represents an actual operator or 
whether it represents a NULL operator which is used as the 
source for external inputs. The xstart and ystart fields 
specify the starting (x,y) coordinates of the operator. The 
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Figure 16 Operator Storage Structure 
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xs top and ystop fields contain the operator's stopping (x,y) 
coordinates. The met field contains a pointer to a Met 
structure which is identical to a Name structure. The last 
three fields are pointers. The head and tail fields point to 
a linked list of lines which leave this operator. The next 
field points to the next operator in the linked list of 
operators . 

As mentioned in the previous paragraph, each operator has 
an associated line list. This line list is a linked list of 
structures of type Line (See Figure 17). These lines 
originate at the operator to which they are attached. 

The name, xstart, ystart, xstop, ystop and next fields of 
the Line structure serve the same purpose as they did in the 
Operator structure. The lntype field is used to identify 
whether the line is an input, output, data stream or a state. 
The dest field is used to point to a name structure which 
holds the name of the operator on which the line terminates. 
For output lines, this field will always point to a name 
structure containing the name EXTERNAL. Figure 18 shows a 
decomposition of an operator. Figure 19 shows the resulting 
storage structure generated during the decomposition process. 

E. ALGORITHM FOR THE GRAPHICAL EDITOR 

At a very high level, the algorithm for the graphical 
editor is simply: 

1) create the window 

2) poll for events 
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Figure 17 Line Storage Structure 



57 




out 3 



Figure 18 Decomposition of an Operator 
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Figure 19 Storage Structure Resulting from 
Operator Decomposition 
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Sun View has built in routines which allow the interface 
designer to construct an interactive window application. The 
interface designer need only provide the routines for 
handling the details of the application. The Appendix 
contains a program listing of the graphical editor. 

1. Create the User Interface 

The user interface for the graphical editor is a 
window comprised of five subwindows, each of which is one of 
the Sun View application building blocks. 

The first step in creating a Sun View application is 
to create a frame. This is done with the Sun Window routine 
window_create . Parameters for this routine allow the 
specification of various attributes for the frame object. 
These attributes include its name, icon, size, location, 
window type, location on the screen and numerous others. 

After the frame has been created, the routine 
window_create is used to create each of the subwindows which 
are used to fill in the frame. The graphical editor frame is 
tiled in with four panel subwindows and a drawing canvas 
subwindow. 

2. Poll for Events 

In conventional interactive programming the main 
event polling loop resides within the application program. A 
notification-based system such as Sun View has the polling 
loop in a notifier. The notifier reads events and then 
notifies the appropriate application procedure that input has 
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occurred. This scheme requires that each procedure must be 
registered with the notifier so that it knows who to call for 
a particular event. The advantage to this is that the system 
takes over the job of managing the event-driven environment. 
[Ref. 14] 

The Sun Window routine panel_create_item is used to 
build a panel subwindow. The parameters for this procedure 
include its name, image type, image label and the procedure 
to be notified when the button is pushed. So procedures 
which are to be called as a result of a button being pushed 
are registered with the notifier by the panel_create_item 
routine . 

a. System Control Events for the Graphical Editor 

The user of the graphical editor must have a 
means of retrieving previously generated diagrams and storing 
new or altered diagrams. He must also have some way to 
terminate the editor. These capabilities are provided by the 
following buttons which are located in the top subwindow of 
the graphical editor frame: 

1) load existing 

2) store 

3) quit 

When the graphical editor is started it comes up in a mode 
which allows the user to create a new decomposition diagram. 

(1) Load Existing. The graphical editor can 
also be started for the purpose of editing a previously drawn 
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decomposition. To load the diagram the user must click on 
the load_existing button. This will cause the routine 
load_proc to read the file graph. pic which contains the 
reconstruction data. This data must have been previously 
retrieved from the design database by the user interface 
[Ref. 6]. When the load_proc routine reads in the 
information for the graphical object, it checks to see if the 
object is an operator. If it is an operator, an operator 
storage element is created, filled in with its information, 
and is attached to the list of operators. If the object is 
of type EXTERNAL, an operator element is also created and is 
linked to the operator list. EXTERNALS are NULL operator 
nodes which serve as the source operator for input lines. The 
only fields of an EXTERNAL which get useful values are those 
pointing at the line list. 

Any object encountered during the load 
process which is not an operator or external is some type of 
line. Therefore, a line storage element is created, its 
values are filled in and it is linked to the line list of the 
last operator which was read in. 

After all of the objects in the file being 
loaded have been read in, stored and linked, the diagram is 
ready to be drawn. Load_proc's final action is to call the 
routine redraw_diagram which traverses the entire linked 
storage structure and draws each object. 
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(2) Store. After the user has completed drawing 
or altering a decomposition diagram, two things must be done. 
First, the information in the diagram must be stored in a 
manner which allows it to be redrawn. Second, the diagram 
must be converted into the equivalent PSDL link statements. 
These link statements will be attached to the implementation 
part of the PSDL specification file by the sequence control 
function [Ref. 6]. 

Information for diagram reconstruction is 
stored by the routine store_diagram . This routine does a 
traversal of the storage structure, writing out the contents 
of each operator node immediately followed by the contents of 
each of its associated line nodes. 

Creating the PSDL link statements is a 
similar process. The create_PSDL routine traverses the 
entire storage structure, generating a PSDL link statement 
for each line node it finds. The link statement is a string 
of characters which result from the concatenation of the 
following six substrings: 

1) the line name (stored in the line node) 

2) the character 

3) the source operator's name (the name of the operator 
whose lines are being processed) 

4) an optional and MET (if the source operator has an 

MET) 

5) the character string"-->" 

6) the destination operator's name (stored in one of the 
line nodes fields) 
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After the diagram has been stored, the 
store_diagram routine tells the system that it is safe to 
exit . 

(3) Quit. The user may terminate the editor by 
clicking on the quit button. This action will cause the 
routine quit_proc to execute. This routine will first check 
to see if the diagram has been stored. If so, it will destroy 
the window. If the diagram has not been saved, an error 
message will appear on the drawing canvas telling the user to 
store the diagram. The user can terminate the session 
without saving by positioning his mouse pointer on the black 
bar at the top of the window and pushing his right mouse. A 
pop-up menu will appear which has quit as one of the choices. 
Selecting this will circumvent the storage check and kill the 
editor . 

b. Mode Select Events 

The graphical editor always starts in the DRAW 
OPERATOR mode. This is because operators must be drawn 
before data streams. This requirement has the advantage of 
making it easy to check the syntax of the diagram. The 
editor ensures that lines intersect operators in the way 
which is appropriate to their type (i.e. input, output, 
etc . ) . 

To switch operating modes, the user clicks on the 
desired mode. The selector will switch to reverse video 
indicating that it has been selected. The selection causes 
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the notifier to call the mode_select routine which sets the 
global edit_mode variable to the appropriate value. This 
establishes the context in which canvas events for the left 
mouse button will be interpreted. 

c. Text Panel Events 

The graphical editor has two panels which provide 
a means of entering textual information. 

(1) Name Panel. The name panel allows the user 
to enter a name for an operator or a line. After the name 
has been typed in, the read_name button must be selected. 
This action causes the notifier to inform the routine 
input_name to read the panel and also causes the routine 
is_valid_ada_id to check the syntax of the name. If the name 
is not a valid Ada identifier, an error message is displayed 
and the system rejects drawing events on the canvas. 

(2) MET Panel. The MET panel works essentially 
the same as the name panel. The only difference is that the 
routine is_valid_MET is used to check that the value is an 
integer and that it has the proper units. Invalid values 
result in an error message and a lockout of operator events 
from the canvas since only operators have an MET. 

d. Canvas Events 

The graphical editor screens the event handler 
for left mouse down events, left mouse drag events, left 
mouse up events and right mouse down events. 
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(1) Left Mouse Down. If the 
process_canvas_events routine receives a left mouse down 
event it will capture the x and y coordinates of the position 
where the event occurred. These values are stored and become 
the starting position of the object being drawn. Which 
object is drawn depends upon the current editing mode. 

(2) Left Mouse Drag Events. If the left mouse 
is down and drag events are detected, the 
process_canvas_events routine will rubberband the object. As 
the mouse pointer is moved across the screen 
process_canvas_events repeatedly captures the position of the 
pointer. For each new position, the routine rubberband is 
called to blank out the previous version of the object and 
then redraw it using the most recent starting and stopping 
coordinates. The result is that the line is erased and 
redrawn as fast as the user moves the pointer across the 
screen . 

(3) Left Mouse Up Events. When a left mouse up 
event occurs, the process_canvas_events routine calls 
rubberband a last time to delete the last rubberbanded 
version then captures the final stopping coordinate. The 
routine process_object then performs the syntactic and 
semantic checks on the object. 

(a) Processing Operators. If the editing 
mode is DRAW OPERATOR, process_ob ject will verify that a name 
and a MET are available and that the coordinates of the new 
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operator do not overlap another operator. When all of these 
conditions are satisfactory it calls the routine 

process_operator . This routine will cause the following 

seven steps to take place: 

1) the object will be drawn 

2) the MET will be retrieved 

3) the name will be retrieved 

4) the name will be displayed, centered in the operator 

5) the MET will be displayed, centered over the operator 

6) the operator will be allocated storage and stored 

7) the stored operator will be appended to the list of 
operators 

(b) Processing Lines. If the editing mode 
is DRAW DATA STREAM, DRAW INPUT, DRAW OUTPUT or DRAW SELF 
LOOP, routine process_object will verify availability of a 
legal Ada identifier and will ensure the line intersects an 
operator in the appropriate fashion. If the checks turn out 
satisfactory, the routine process_line is called. This 
routine will cause the following actions: 

1) draw the appropriate line 

2) draw the arrowhead on the end of the line 

3) if the line is an input line: 

a. creates a NULL operator to act as its source 

b. links the NULL operator to the operator list 

4) retrieves the line's name 

5) displays the name on the line 

6) creates the storage for the line and fills in the 
values 
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7) appends the line to the source operator's list of 
lines 

(4) Right Mouse Down Events. When a right mouse 
down event occurs, the routine process_canvas_events checks 
to see if the mouse's coordinates are within the pick 
criteria of either a line or an operator. If so, the object 
is deleted from the storage structure by routine delete_line 
or delete_op as appropriate. After the deletion is complete, 
routine redraw_diagram draws the remaining objects. 
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V. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

This thesis shows that a graphical editor for performing 
hierarchical decomposition of composite PSDL operators can be 
designed and implemented. It also demonstrates that a linked 
list of operators each containing a linked list of outputs is 
an effective method of storing the graphical elements. This 
is evidenced by the speed which diagrams can be loaded, 
stored, redrawn and deleted from. This method of storage is 
also shown to support the transformation of a pictorial 
diagram into textual PSDL link statements. 

It also shows that through the use of modes, the 
graphical editor can perform syntactic and semantic checks 
during the decomposition. These checks ensure that the PSDL 
link statements are always of the proper form and convey the 
designer's intended meaning. 

Research on the graphical editor, as it relates to PSDL, 
indicates that the prototype design will take shape in the 
editor. Therefore, there is a need to start new 
specification files for each new operator introduced during a 
decomposition. Each of these new files will contain the 
operator's name, inputs, outputs, states and MET. 

This research indicates that using the graphical editor 
to randomly edit up and down through the objects in the 
design database has the potential to cause inconsistencies 



69 



between the specification of an operator and its pictorial 
values. A better method would be to make corrections in a 
top-down fashion, alternating between graphical editor and 
the syntax directed editor for each object. This method, 
although slower, would ensure view consistency between the 
textual and graphical representations of the decomposition. 



B . RECOMMENDATIONS 

1) The requirement that forces the user to enter the 
textual values for an object before it is drawn 
decreases the user friendliness of the graphical 
editor. A method should be developed which allows 
entry of this textual information at any time during 
the decomposition process. 

2) Work should be done to make the system configurable. A 
user should be able to disable checking and therefore 
enter any object in any order desired. This would 
greatly improve its appeal to the expert user. 

3) The process of decomposing an operator is like 
programming with objects. A better way to enter an 
operator's specification might be to open a window 
within the graphical editor which allows the user to 
define the object as it is being created instead of 
using a syntax directed editor to enter its 
specification . 

4) Currently the graphical editor only supports prototypes 
written in Ada. Providing a panel with a choice of 
languages, which would enable an appropriate identifier 
syntax checker, would make the editor less language 
specific . 

5) Currently all error messages are displayed on the 
drawing canvas. A better method would be to display 
them in dialogue boxes. 

6) The user should be able to just "pick" the names of all 
external data streams from a list of inputs and 
outputs, that are passed to the editor when it is 
invoked, rather than being required to type them. This 
would eliminate another possible source of errors. 
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APPENDIX 



PROGRAM TEXT FOR THE GRAPHICAL EDITOR 



♦include 

♦include 

♦include 

♦include 

♦include 

♦include 

♦include 

♦include 



<stdio.h> 

<suntool/sunview . h> 
<suntool/canvas .h> 
<suntool /panel . h> 
<suntool/seln .h> 
<math .h> 

<string . h> 

<ctype .h> 



/* define constants for the object types */ 

♦define OPERATOR 0 
♦define DATA_STREAM 1 
♦define SELF_LOOP 2 
♦define INPUT 3 
♦define OUTPUT 4 
♦define EXTERNAL 5 



♦define PI 3.141592654 



/* constant PI */ 



♦define DISP_WIDTH 140 
♦define DISP_HT 50 



/* display width */ 
/* display height */ 



♦define ARROW_LENGTH 9 
♦define TEXT_MAX_LEN 35 
♦define TIME_MAX_LEN 10 



/* 



/* length of the arrow head 
/* length of name which is visible 
length of the met which is visible 



*/ 

*1 

*/ 



♦define PROXIMITY 25 



/* define size of line pick region */ 



/* import predefined editor icon */ 

static short editor_icon [ ] = { 

♦include "/ us r /suns 2 /thorsten/graphics /editor . icon" 

} ; 



DEFINE_ICON_FROM_IMAGE (editor, editor_icon) ; 



Frame frame; 

Panel op_mode_panel, 

edit_mode_panel , 

metjpanel, 

narae_panel; 



/* handle for frame */ 

/* handle for top panel */ 
/* handle for side panel */ 
/* handle for met panel */ 
/* handle for name panel */ 



Canvas drawing_canvas ; 



/* handle for drawing canvas */ 



Event ‘event 



/* handle for events */ 
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Pixf ont 



'bold; 



/* handle for borders */ 



Pixwin 


*drawing_pw; 


int 


edit_mode; 


int 


name_checked = 0, 




met_checked = 0; 


int 


graph_saved = 0; 



/* handle for drawing pixwin */ 

/* global - stores the current edit mode */ 

/* global - signals that name is valid */ 
/* global - signals that met is valid */ 

/* global - signals saved status */ 



Panel_item object_name, 

t ime_const ra int ; 



/* handle for name */ 
/* handle for met */ 



char *name_buf, 
*met_buf ; 



/* global - buffer to read the name into */ 
/* global - buffer to read the met into */ 



FILE 



*f, 

*g; 



/* PSDL link statement file */ 
/* file which holds the reconstruction info */ 



typedef struct /* storage struct for names and mets */ 

{ 



int 


length; 




/* string length 


*/ 


char 


string [ 40 ] ; 


/* array to hold 


the name or met string 


*/ 


} Name, Met 










typedef struct line 


/* 


line storage structure 


*/ 


Name 


*name; 




/* name of line 


*/ 


int 


lntype ; 


/* identifies 


the type of line it is 


*/ 


int 


xstart ; 


/* x coord 


of line starting posit 


*/ 


int 


ystart; 


/* y coord 


of line starting posit 


*/ 


int 


xstop; 


/* x coord 


of line stopping posit 


*/ 


int 


ystop; 


/* y coord 


of line stopping posit 


*/ 


Name 


*dest ; 


/* operator on which line terminates 


*/ 



struct line *next; /* pointer to next line in this list */ 

}Line; 



typedef struct operator /* operator storage stucture */ 

{ 



Name 


*name; 




/* operator's name 


*/ 


int 


optype; 


1 * identifies contents as operator or external 


*/ 


int 


xstart ; 


/* x coord 


where operator should start to be drawn 


*/ 


int 


ystart; 


/* y coord 


where operator should start to be drawn 


*/ 


int 


xstop; 


/* x 


coord of the operator's opposite corner 


*/ 


int 


ystop; 


/* y 


coord of the operator's opposite corner 


*/ 


Met 


*met; 


/* 


maximum execution time for the operator 


*/ 


Line 


*head; 




/* head of the operator's output list 


*/ 


Line 


*tail; 




/* tail of the operator's output list 


*/ 
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/* pointer to next operator in list */ 



struct operator ‘next; 
}Operator ; 



/* the list for operators */ 

/* pointer to the head of the list */ 
/* pointer to the tail of the list */ 



typedef struct 
{ 

Operator ‘head; 
Operator ‘tail; 
]Operator_list; 



Operator_list operator_list ; 
Operator_list *op_list = &operator_list; 

Operator *op, *sop, *dop; 

Name name_pointer ; 

Name ‘name = &name_pointer; 

Met *tc; 

Line *ln; 



/* forward declarations of functions */ 

static Notify_value process_canvas_events ( ) ; 

static Notify_value mode_select ( ) ; 

Operator *alloc_operator ( ) ; 

Operator *pick_operator { ) ; 

Operator *create_op ( ) ; 

Line *alloc_line ( ) ; 

Line *pick_line ( ) ; 

Line *create_line { ) ; 

Name ‘external (); 

Name *get_name ( ) ; 

Met *get_met(); 

int is_op_pick ( ) ; 

int is_line_pick ( ) ; 

int is_valid_ada_id ( ) ; 

int is_valid_met ( ) ; 



/* forward declarations of procedures */ 

help_proc < ) ; 
quit_proc () ; 
load_proc ( ) ; 
store_proc ( ) ; 
input_name { ) ; 
input_met ( ) ; 
append_line_to_op ( ) ; 
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is_op_pick ( ) ; 
is_input_pick. ( ) ; 
process_operator ( ) ; 
process_line ( ) ; 
rubber_band ( ) ; 
redraw_diagram() ; 
delete_line ( ) ; 
delete_op () ; 
delete_input_lines () ; 
display_error_msg () ; 
display_name ( ) ; 
display_met () ; 
draw_arrowhead ( ) ; 
draw_ob ject ( ) ; 
create_PSDL ( ) ; 
store_diagram() ; 
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ma in ( a rgc , a rgv ) 



WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS : create_operating_mode_panel () 
create_editing_mode_panel () 
create_name_panel ( ) 
create_met_panel ( ) 
process_canvas_events () 

CALLED BY: N/A 

PURPOSE: creates the frame and the subwindows which comprise the 
graphical editor. It also registers the routine 
process_canvas_e vents with the notifier. 



int argc; 
char **argv? 



{ 



/* cause borders to highlight if region entered */ 
bold = pf_open ("/usr/lib/fonts/fixedwidthfonts/screen.b. 12") ; 
if (bold == NULL) exit(l); 



/* create the outer display frame */ 



window^create (NULL, FRAME, 
FRAME_LABEL , 

FRAME_ICON, 

FRAME_CMDLINE_HELP_PROC , 
FRAME_ARGS , 
WIN_ERROR_MSG, 

WIN_X, 

WIN_Y, 

WIN_ROWS, 

WIN_COLUMNS , 

0 ) ; 



"graphical editor", 
Seditor, 
he lp_proc, 
argc, argv, 

"can't create window. 
15, 

15, 

DISP_HT, 

DISP_WIDTH, 



/* create op_mode_panel */ 

op_mode_panel = window_c reate (frame, PANEL, WIN_FONT , bold, 0); 
create_operating_mode_panel ( ) ; 



/* create editing mode panel */ 

edit_mode_panel = window_create (frame, PANEL, WIN_F0NT, bold, 0) ; 
create_editing_mode_panel () ; 



/* create panel to read object names */ 
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name_panel = window_create (frame, PANEL, WIN_FONT, bold, 0) ; 
create_name_panel ( ) | 



/* create panel to read operator's met */ 
met_panel = window_create (frame, PANEL, WIN_FONT, bold, 0); 
create_met_panel () ; 



/* create canvas to draw on */ 

drawing_canvas = window_create ( frame, CANVAS, WIN_FONT, bold, 

WIN_CONSUME_KBD_EVENT, WIN_ASCI I_EVENTS , 
WIN_EVENT_PROC, process_canvas_events, 
CANVAS_RETAINED , TRUE, 0) ; 



/* cause drag events to be accepted */ 
window_set (drawing_canvas, WIN_CONSUME_PICK_EVENT, LOC_DRAG, 0) ; 

/* define drawing pixwin */ 
drawing_pw = canvas_pixwin (drawing_canvas) ; 



/* initialize the operator list */ 
operator_list . head = operator_list . tail = NULL; 



window_main_loop (frame) ; 



/* poll for events in the frame */ 



} /* end main */ 
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create_operating_mode_panel ( ) 



WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: load_proc() 
store_proc ( ) 
quit_proc () 

CALLED BY: main() 

PURPOSE: This routine builds the top panel of the display which 
contains the operating mode buttons. It also registers 
the routines load_ proc, store_proc, and quit_proc with 
the notifier. 




/* display panel message */ 
panel_create_item(op_mode_panel, PANEL_MESSAGE, 

PANEL_LABEL_STRING, 



(left mouse selects) ", 0) ; 

/* create button to load reconstruction info */ 
pane l_c r e a t e_i t em ( op_mode_pa ne 1 , PANE L_BUTTON , 

PANEL_LABEL_IMAGE, panel_button_image (op_mode_panel, 

"Load Existing", 0, 0) , 

P ANE L_N OT I F Y_P ROC , load_proc, 0 ) 7 

/* create button to store the diagram */ 
panel_create_item(op_mode_panel, PANEL_BUTTON, 

PANEL_LABEL_IMAGE, panel_button_image (op_mode_panel, 

"Store", 0, 0), P ANE L_NO T I F Y_P ROC , store_proc, 0); 

/* create button to terminate the program */ 
panel_create_item ( op_mode_panel , P ANEL_BUTTON, 

P ANEL_LABEL_IMAGE , panel_button_image (op_mode_panel, 

"Quit", 0, 0), 

PANEL_NOTIFY_PROC, quit_proc, 0); 

/* fit border around the top panel */ 
window_f it_height (op_mode_panel ) ; 

) /* end create_operating_mode_panel */ 
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create_editing_mode_panel () 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS : mode_select ( ) 

CALLED BY: main() 

PURPOSE: This routine builds the edit mode panel and registers the 
routine mode_select with the notifier. 




/* put blank line in panel */ 
panel_create_item (edit_mode_panel, PANEL_MESSAGE, 

PANEL_LABEL_STRING, 



0 ) ; 



panel_create_item (edit_mode_j>anel, 
PANEL_LABEL_STRING, 
PANEL_CHOICE_STRINGS, 



PANEL_FEEDBACK, 

P ANE L_NOT I F Y_P ROC , 



/* create the mode select panel */ 
PANEL_CHOICE, 

Editing Mode: ", 

Draw Operator ", 

Draw Data Stream ", 

Draw Self Loop ", 

Draw Input ", 

Draw Output ", 

0 , 

PANEL_INVERTED , 
mode_select, 0) ; 



/* insert a blank line below the menu */ 
panel_create_item(edit_mode_j>anel, PANEL_MESSAGE, 

PANEL_LABEL_STRING, 



/* fit window around the editing mode panel */ 
window_f it_height (edit_mode_panel) ; 

} /* end create_editing_mode_panel */ 
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create_name_panel () 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS : input_name ( ) 

CALLED BY: main() 

PURPOSE: This routine creates the panel which reads the names which 
are assigned to objects. It also registers the routine 
input_name with the notifier. 



***********************************************************************/ 

{ 

/* put in a header */ 

object_name = panel_create_item (name_panel, P ANEL_TEXT , 
PANEL_LABEL_STRING, " Identifier Name:”, 

P ANE L_VALUE , 

P ANE L_VALUE_D I SP LAY_LENGTH , TEXT_MAX_LEN , 

0 ) ; 

/* create read button and register input text with the notifier */ 
panel_create_item(name_panel, PANEL_BUTTON, 

PANEL_LABEL_IMAGE, panel_button_image (name_panel, 

"read name", 0,0), 

P ANE L_N OT I F Y_P ROC , input_name, 

0 ) ; 



/* put top and bottom boundary on the panel */ 
window_f it_height (namejsanel) ; 

} /* end create_name_panel */ 
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create_met_j?anel () 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS : input_met ( ) 

CALLED BY: main() 

PURPOSE: This routine creates the panel which reads the maximum 
execution times which are assigned to the operators. It 
also registers the routine input_met with the notifier. 



***********************************************************************/ 

{ 

/* put in a header */ 

time_constraint = panel_create_item (met_j?anel , P ANEL_TEXT , 
PANEL_LABEL_STRING, " Max Exec Time 

P ANEL_VALUE , 

PANEL_VALUE_D I SPLAY_LENGTH , T IME_MAX_LEN , 

0 ) ; 



/* insert some spaces to align the read buttons */ 
panel_create_item (met_j>anel, PANEL_MESSAGE, 

PANEL_LABEL_STRING, " ", 

0 ) ; 

/* create read met button and register input_met with the notifier */ 
pane l_crea te_item (met_pane 1 , PANEL_BUTTON , 

PANEL_LABEL_IMAGE, panel_button_image (met_panel, 

"read met", 0,0), 

P ANE L_N OT I F Y_PROC , input_met, 

0) I 



/* put top and bottom boundary on the panel */ 
window_f it_height (met_panel) ; 

) /* end create_met_j>anel */ 
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static Notify_value 
mode_select (item, value, event) 

WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: create_editing_mode_panel ( ) 

PURPOSE: This routine establishes the mode that the editor is 

operating in by setting the global variable edit_mode to 
one of the predefined constants for the objects. 



Panel_item item; 
int value ; 

Event * event; 



switch (value) 

{ 

case OPERATOR: 

edit_mode = OPERATOR; 
break; 



case DATA_STREAM : 



edit_mode 

break; 



DATA_STREAM; 



case SELF LOOP : 



edit_mode 

break; 



SELF_LOOP ; 



case INPUT: 



edit_mode = INPUT; 
break; 



case OUTPUT: 



edit_mode = OUTPUT; 
break; 



default : 



break; 



) 

return; 

} /* end mode select proc */ 
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quit_proc ( ) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: display_error_msg ( ) 

CALLED BY: create_editing_mode_panel ( ) 

PURPOSE: This routine checks to see if the diagram has been 

stored and if so, terminates the program and clears the 
display. If the diagram has not been saved it causes an 
error message to be displayed and does not terminate 
execution . 



{ 



if (graph_saved) 

{ 

/* destroy the window */ 
window_set (frame, FRAME_NO_CONFIRM, TRUE, 0) ; 
window_destroy (frame) ; 



else 

i 

display_error_msg (6) ; /* graph not saved message */ 

} 

} /* end quit_proc */ 
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load_proc ( ) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 



CALLS : create_op ( ) 

append_to op_list() 
create_line () 
append_line_to_op ( ) 
redraw_diagram ( ) 

CALLED BY: create_operating_mode_panel ( ) 

PURPOSE: This routine loads a diagram which is in the file 
graph. pic and causes it to be redrawn. 



{ 

int optype, xl , yl , x2, y2 ; 

Name *oname, 

*dest ; 

Met *tc; 

graph_saved = 0; 
g = fopen ("graph .pic" , "r") ; 

while (!feof(g)) 

{ 

oname = (Name *)malloc (sizeof (Name) ) ; /* alloc name storage */ 

f scanf (g, ”%d\n", &optype) ; /* read in values */ 

f scanf (g, "%d\n", 6x1) ; 
f scanf (g, ”%d\n", 6yl) ; 
f scanf (g, ’^dXn'', 6x2) ; 
f scanf (g, "%d\n", 6y2) ; 
f scanf (g, "%s\n", oname->string) ; 

oname->length = strlen (oname->string) ; /* calc name length */ 

if ( (optype == OPERATOR) | I (optype == EXTERNAL) ) 

{ 

tc = (Met *)malloc (sizeof (Met) ) ; /* alloc met storage */ 

fscanf (g, ”%s\n",tc->string) ; /* read met */ 

tc->length = strlen (tc->string) ; /* calc met length */ 

op = create_op (oname, optype, xl, yl, x2, y2 , tc) ? /*alloc node */ 
append_to_op_list (op_list, op) ; /* attach node to list */ 



else 

{ 

dest = (Name *)malloc (sizeof (Name) ); /*alloc dest name stg */ 
fscanf (g, "%s\n" , dest->string) ; /* read dest name */ 

dest->length = strlen (dest->string) ; /* calc name length */ 
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dop = create_op (dest , optype, xl , yl , x2 , y2 , tc) ; /*alloc node */ 
In = create_line (oname, optype, xl, yl, x2, y2, dop) ; /*alloc In*/ 
append_line_to_op (op, In) ; /* attach line to its source */ 

} 

} 

f close (g) ; 
redraw_diagram ( ) ; 

} /* end load_proc */ 



store_proc ( ) 



WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: create_PSDL ( ) 

store_diagram ( ) 

CALLED BY: create_operating_mode_panel ( ) 

PURPOSE: This routine stores the diagram in the file graph. pic. 

Prior to storing the diagram it causes the picture to be 
transformed into the equivalent PSDL link statements. 




create_PSDL ( ) ; 
store_diagram ( ) ; 
graph_saved = 1; 



} /* end store_proc */ 
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static Notify_value 

process_canvas_e vents (canvas, event ) 

WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS : pick_line ( ) 

delete_line ( ) 
pick_operator () 
delete_op ( ) 
redraw_diagram ( ) 
rubber_band ( ) 
process_ob ject () 

CALLED BY: main() 

PURPOSE: This routine processes canvas events. It determines what 
actions will take place for a given mouse event. 



Canvas canvas; 

Event *event; 

{ 

int id = event_id (event) ; 
static int xl, yl, x2, y2; 
static int new_posit = 1; 
static int left_button = 0; 
static int middle_button = 0; 

Operator *op; 

Line *ln; 

if (event_is_button (event) ) 

{ 

if (event_is_down (event) ) 

{ 

xl = event_x (event ) ; 
yl = event_y (event) ; 
switch (id) 

{ 

case MS_LEFT : 

new_posit = 1; 
x2 = xl; 

y2 = yl; 

lef t_button=l 
break; 

case MS_MIDDLE : /* do nothing */ 

break; 



/* check for button events */ 
/* check for down events */ 
/* position of button down event */ 

/* save starting posit */ 
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case MS_RIGHT: /* pick object for deletion */ 

if ({In = pick_line (op_list, xl, yl) ) != NULL) 

< 

op = NULL; 

delete_line (op_list, op, In) ; 

} 

else if ( (op= pick_operator (op_list, xl, yl) ) != NULL) 

delete_op (op_list, op) ; 
redraw_diagram ( ) ; 
break; 

) 

} 

else if (event_is_up (event) ) /* check for up events */ 

{ 

switch (id) 

{ 



case MS_LEFT: 

rubber_band(xl,yl,x2,y2) ; /* blank out object */ 
x2 = event_x (event) ; /* store new stop coords */ 
y2 = event y (event) ; 



process_object (xl,yl,x2,y2) ; /* draw final obj */ 

lef t_button=0 ; 

break; 

case MS_MIDDLE: /* do nothing */ 

break; 



case MS_RIGHT: 
break; 

} 

1 

} 

else if (id == LOC_DRAG) 

{ 

if (left_button) 



/* do nothing */ 



/* check for drag events */ 



if (!new_posit) 

/* rubber band operator's boundary while being drawn */ 

{ 

rubber_band(xl,yl,x2,y2) ; /* erase previous image */ 

x2 = event_x (event ) ; /* get new stop coords */ 

y2 = event_y(event); 

rubber_band(xl,yl,x2,y2) ; /* redraw the object */ 

} 

else 

new__posit = 0; 

} 

} 

return; 

) /* end process_canvas_events */ 
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process_ob ject (xl, yl, x2, y2) 

WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS : pick_operator ( ) 

process_operator () 
display_error_msg ( ) 
process_line ( ) 

CALLED BY: process_canvas_e vents ( ) 

PURPOSE: This routine determines if an object meets the criteria 
to be drawn. 



int xl,yl,x2,y2; 

{ 

Operator *op, *sop, *dop; 

switch (edit_mode) 

{ 

case OPERATOR: 

if (name_checked && met_checked) 

{ /* draw the object if it is*/ 

/* not positioned on top of*/ 
/* an existing object */ 

if ( ( (pick_operator (op_list , xl , yl) ) ==NULL) && 

( (pick_operator (op_list , x2 , y2 ) ) ==NULL) ) 

f 

process_operator (OPERATOR, xl , y 1 , x2 , y2 ) ; 

) 

) 

else 

< 

display_error_msg ( 4 ) ; /* name or met not checked */ 

} 

break; 

case DATA_STREAM : 

if (name_checked) 

( 

/* draw line if it starts and */ 
/* terminates on an operator */ 
if ( ( (sop=pick_operator (op_list, xl, yl) ) ! =NULL) && 

( (dop=pick_operator (op_list , x2 , y2 ) ) !=NULL) && 

(sop ! = dop) ) 

{ 

process_line (DATA_STREAM, xl, yl, x2, y2, sop, dop) ; 
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else 



{ 

display_error_msg (5) ; /* name not checked 

} 

break; 



case SELF_LOOP : 

if (name_checked) 



/* draw the loop if it 
/* starts on an object and 
/* is not intersecting 
/* an existing object 

if ( ( (sop=pick_operator (op_list, xl, yl) ) !=NULL) && 

( (dop=pick_operator (op_list , x2 , y2 ) ) ==NULL) ) 

< 

process_line (SELF_LOOP, xl, yl, x2 , y2 , sop, sop) ; 



} 

else 



{ 

display_error_msg (5) ; 

} 

break; 



/* name not checked 



if (name_checked) 

{ 

/* draw line if it ends 
/* on an operator 

if ( ( (sop=pick_operator (op_list, xl, yl) ) ==NULL) && 

( (dop=pick_operator (op_list , x2 , y2 ) ) !=NULL)) 

{ 

process_line ( INPUT, xl , yl , x2 , y2 , sop, dop) ; 

} 

} 

else 

{ 

display_error_msg (5) ; /* name not checked 

} 

break; 

case OUTPUT: 

if (name_checked) 

{ 

dop = NULL; 

/* draw the line if it 
/* starts on an operator 
/* and doesn't terminate on one 



*/ 



*/ 

*/ 

*/ 

*/ 



*/ 



*/ 

*/ 



*/ 



*/ 

*/ 

*/ 
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if ( ( (sop=pick_operator (op_list, xl, yl) ) !=NULL) && 

( (dop=pick_operator (op_list, x2, y2) ) ==NULL) ) 

{ 

process_line (OUTPUT, xl, yl, x2, y2, sop,dop) ; 

) 

1 

else 

( 

display_error_msg (5) ; /* name not checked */ 

1 

break; 

default : 
break; 

} 



! /* end_process_ob ject */ 
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draw_object (otype, xl, yl, x2 , y2) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: process_operator ( ) 
process_line ( ) 
redraw_diagram ( ) 

PURPOSE: This routine causes the object to be drawn in final form. 



int otype, xl, yl, x2, y2 ; 

< 

float i, xmid, ymid, xcent , ycent ; 
int xnew, ynew, xold, yold; 



switch (otype) 

{ 

case OPERATOR: 

xmid = (x2-xl)/2.0; 
ymid = (y2-yl)/2.0; 

xcent = xl + xmid; 
ycent = yl + ymid; 

/ 

xold = x2 ; 
yold = ycent; 



/* calc objects midpoint 



/* objects center point on the screen 



position to start drawing the object 



*/ 



*/ 



*/ 



/* loop to draw the object */ 
for ( i = 0.0; i <= 2 * PI; i = i + PI / 12) 

{ 

/* draw line segments of an oval */ 
xnew = xcent + (xmid * cos(i)); 

ynew = ycent + (ymid * sin(i)); 

pw_vector (drawing_jpw, xold, yold, xnew, ynew, PIX_SRC, 

1 ) ; 

xold = xnew; 

yold = ynew; 

) 

break; 
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case DATA_STREAM: 



/* draw line from (xl,yl) to (x2,y2) */ 
pw_vector (drawing_pw, xl, yl, x2, y2, PIX_SRC, 1) ; 
break; 



case SELF_LOOP : 

pw_vector (drawing_pw, 
pw_vector (drawing_pw, 
pw_vector (drawing_pw, 
break; 



/* 

x2, 

x2, 

xl, 



draw three sides of a rectangle */ 



yi. 


x2. 


y2. 


PIX_ 


_SRC, 


1) 


y2. 


xl. 


y2. 


PIX_ 


SRC, 


1) 


y2, 


xl. 


yi, 


PIX_ 


SRC, 


1) 



case INPUT: 

/* draw line from (xl,yl) to (x2,y2) */ 
pw_vector (drawing_pw, xl, yl, x2, y2, PIX_SRC, 1); 
break; 



case OUTPUT: 

/* draw line from (xl,yl) to (x2,y2) */ 
pw_vector (drawing_pw, xl, yl, x2, y2, PIX_SRC, 1) ; 
break; 



) 



default : 
break; 



/* end draw_object */ 
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rubber_band (xl, yl, x2, y2) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: process_canvas_events ( ) 

PURPOSE: This routine draws the object during the rubber banding 
process. An operator is drawn as a rectangle by this 
routine . 



int 

{ 



xl,yl,x2,y2; 



switch (edit_mode) 

{ 

case OPERATOR: 

pw_vector (drawing_pw, xl, 
pw_vector (drawing_j?w, x2, 
pw_vector (drawing_pw, x2, 
pw_vector (drawing_pw, xl, 
break; 



yl, x2, 
yl, x2 , 
y2, xl, 
y2 , xl, 



yl, PIX_NOT (PIX_DST) 
y2 , PIX_NOT (PIX_DST) 
y2 , PIX_NOT (PIX_DST) 
yl, PIX_NOT (PIX_DST) 



***/ 



1 ) 

1 ) 

1 ) 

1) 



case DATA_STREAM : 

pw_vector (drawing_pw, xl, yl, x2, y2, PIX_NOT (PIX_DST) , 1) ; 
break; 



case SELF LOOP : 

pw_vector (drawing_pw, x2, yl, x2, 
pw_vector (drawing__pw, x2, y2, xl, 
pw_vector (drawing_pw, xl, y2, xl, 
break; 



y2 , PIX_NOT (PIX_DST) , 
y2 , PIX_NOT (PIX_DST) , 
yl, PIX_NOT (PIX_DST) , 



1 ) ; 
l) ; 
l) ; 



case INPUT: 

pw_vector (drawing_pw, xl, yl, x2, y2, PIX_NOT (PIX_DST) , 1); 
break; 



case OUTPUT: 

pw_vector (drawing_pw, xl, yl, x2, y2, PIX_NOT (PIX_DST) , In- 
break; 



default : 

break; 



} /* end rubber_band */ 
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process_operator (otype, xl , yl, x2, y2) 



WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS : draw_ob ject ( ) 
get_met ( ) 
display_name ( ) 
display_met () 
create_op ( ) 
append_to_op_list () 

CALLED BY: process_ob ject ( ) 

PURPOSE: This routine manages the process of drawing, labeling 
storing, and linking an operator. 



int otype, xl,yl,x2,y2; 



Name *obj_name; 
Met *tc; 
Operator *op; 



draw_object (otype, xl, yl, x2, y2) ; 
tc = get_met(); 
obj_name = get_name(); 

display_name (obj_name, otype, xl , yl , x2 , y2) ; 
display_met (tc, xl , yl , x2 , y2 ) ; 

op = create_op (obj_name, otype, xl , yl , x2 , y2 , tc) ; 
append_to_op_list (op_list,op) ; 
name_checked = 0; 
met_checked = 0; 

} /* end process_operator */ 



95 



process_line (otype, xl, yl, x2 , y2, sop, dop) 



WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: draw_object () 

draw_arrowhead ( ) 
get_met ( ) 
external ( ) 
create_op ( ) 
append_to_op_list ( ) 
get_name ( ) 
display_name () 
create_line ( ) 
append_line_to_op ( ) 

CALLED BY: process_ob ject ( ) 

PURPOSE: This routine manages the process of drawing, labeling 
storing, an linking lines . 



int otype, xl, yl, x2 , y2 ; 
Operator *sop,*dop; 



Name *obj_name, *op_name; 

Line *ln; 

draw_ob ject (otype, xl, yl, x2, y2) ; 
if (Otype == SELF_LOOP) 

draw_arrowhead (x2 , y2 , x2 , yl) ; 

else 

draw_arrowhead (xl, yl, x2, y2) ; 

if (otype == INPUT) 

{ 

tc = get_met ( ) ; 
op_name = external (); 

sop = create_op (op_name, EXTERNAL, xl, yl, x2, y2 , tc) ; 
append_to_op_list (op_list, sop) ; 

} 

obj_name = get_name(); 

display_name (ob j_name, otype, xl, yl, x2, y2 ) ; 

In = create_line (obj_name, otype, xl, yl, x2, y2, dop) ; 
append_line_to_op (sop, In) ; 
name_checked = 0; 

} /* end process_line */ 
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Operator * 

create_op (name, op_type, xl , yl , x2 , y2 , tc) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 



CALLS: alloc_operator ( ) 

CALLED BY: load_proc() 

process_operator () 
process_line ( ) 

PURPOSE: This routine stores all the info for an operator in a 
structure . 



Name 

int 

Met 

{ 



*name; 

op_type , xl , yl , x2 , y2 ; 
*tc; 



Operator *new_op; 

new_op = alloc_operator ( ) ; /* get storage for the operator 

/* fill in the values for the operator 

new_op->name = name; 
new_op->met = tc; 
new_op->head = NULL; 
new_op->tail = NULL; 
new_op->next = NULL; 
switch (op_type> 

{ 



case OPERATOR: 

new_op->optype 

new_op->xstart 

new_op->ystart 

new_op->xstop 

new_op->ystop 

break; 



case EXTERNAL: 



xl; 

yi; 

x2 ; 
y2; 



default : 



new_op->optype = EXTERNAL; 
new_op->xstart = 0; 
new_op->ystart = 0; 
new_op->xstop = 0; 
new_op->ystop - 0; 
break; 



break; 

) 

return (new_op) ; 

} /* end create_op */ 



*/ 



*/ 

*/ 
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Line * 

create_line (name, ln_type, xl , yl, x2 , y2 , dest_op) 

WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: alloc_line() 

CALLED BY: load_proc() 

process_line () 

PURPOSE: This routine stores the information for a line in a line 
structure . 



Name 

int 

int 

Operator 

{ 



*name; 

ln_type; 

xl,yl,x2,y2; 

*dest_op; 



Line *new_ln; 



new_ln = alloc_line ( ) ; 

/ 

new_ln->name = name; 
new_ln->xstart = xl; 
new_ln->ystart - yl; 
new_ln->xstop = x2; 
new_ln->ystop = y2; 
new_ln->next = NULL; 
switch (ln_type) 

{ 

case INPUT: 



new_ln->lntype 

new_ln->dest 

break; 



/* get storage for the line */ 



fill in the values for the line */ 



INPUT; 

dest_op->name ; 



case DATA_STREAM: 

new_ln->lntype 

new_ln->dest 

break; 



DATA_STREAM; 

dest_op->name; 



case OUTPUT: 



new_ln->lntype = OUTPUT; 
new_ln->dest = external (); 
break; 



case SELF_LOOP : 

new_ln->lntype 



= SELF_LOOP ; 
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new_ln->dest = dest_op->name; 
break; 

default : 

break; 

} 

return (new_ln) ; 

} /* end create_line */ 



delete_op (op_list, op) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS : delete_input_lines ( ) 

CALLED BY: process_canvas_events ( ) 

PURPOSE: This routine deletes an operator from the list of 
operators and frees up the storage. 



Operator_list *op_list; 
Operator *op; 



{ 

Operator *dptr, 

* otemp; 

Line *lptr, 

*ltemp; 
Name *n; 



n = op->name; 

delete_input_lines (op_list,n) ; 

otemp = op_list->head; 

if (op != otemp) /* 

{ 

while (otemp->next != op) 

{ 

otemp = otemp->next; 

) 

dptr = otemp->next; 



/* find lines which terminate on */ 
/* this operator and delete them */ 

/* put pointer at head of op list */ 
is the first op the one to delete? */ 
/* if not, find the one to delete */ 

/* unlink the op to be deleted */ 
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if (dptr->next != NULL) 

{ 

otemp->next = dptr->next; 
dptr->next = NULL; 



else 

otemp->next = NULL; 



else /* 

{ 

dptr = op_list->head; 
op_list->head = dptr->next; 

} 

if (dptr->head != NULL) 

{ 

ltemp = dptr->head; 
lptr = dptr->head; 
dptr->head = NULL; 
while (lptr->next != NULL) 

{ 

lptr = lptr->next; 
free (ltemp) ; 
ltemp = lptr; 

} 

free (lptr) ; 
lptr = NULL; 
ltemp = NULL; 

} 

free (dptr) ; 
dptr = NULL; 

}/* end delete_op */ 



the first one is the one to delete */ 
/* unlink the first op */ 

/* does it have any assoc lines ? */ 
/* if so, free up their storage */ 



/* free up the last line's storage */ 



/* free up the operator's storage */ 
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delete_input_lines (op_list,n) 

WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS : delete_line ( ) 

CALLED BY: delete_op() 

PURPOSE: This routine finds all of the input lines for an 

operator which has been deleted and causes them to be 
deleted. 



Operator_list *op_list; 
Name *n; 



Operator *optr; 
Line *lptr, 

*ltemp; 



optr = op_list->head; 
while (optr != NULL) 

{ 

lptr = optr->head; 
while (lptr != NULL) 



/* start at head of operator list */ 
/* search the entire list of operators */ 

/* start inner ptr at head of line list */ 
/* check each line leaving each operator */ 



if ( ! strcmp (n->string, lptr->dest->string) ) 

{ 

ltemp = lptr->next; 

/* found a line with the */ 
/* destination searched for */ 
delete_line (op_list, optr, lptr) ; /* so delete it */ 

lptr = ltemp; 



else 

{ 

lptr = lptr->next; /* go to the next line */ 

} 

} 

optr = optr->next; /* go to the next operator */ 



!■ /* end delete_input_lines */ 
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delete_line (op_list, op. In) 



WRITTEN BY: R. K. Thorstenson 



LAST MODIFIED: 10 Nov 1988 



CALLS: N/A 

CALLED BY: delete_input_lines ( ) 

process_canvas_events () 

PURPOSE: This routine deletes a line from an operator's line 

list. If the source operator is not known, it will search 
through all of thelists until it is found. 



Operator_list *op_list; 
Operator *op; 

Line *ln; 



Operator *optr; 

Line *lptr, 

*ltemp; 

int ln_found = 0; 



if (op != NULL) /* the line's source op is known */ 

{ 

opt r = op; /* start the search for the line at its source op */ 
lptr = optr->head; 
ltemp = lptr; 

while (lptr != In) /* skip the lines which don't match */ 



ltemp = lptr; 
lptr = lptr->next; 

) 

} 

else /* source op is unknown - find the line */ 

| 

optr = op_list->head; /* start at beginning of op list */ 

while ( (optr != NULL) && (!ln_found)) /* search until found */ 

{ 

lptr = optr->head; /* start at head of line list */ 

ltemp = lptr; 

while ((lptr != NULL) && (!ln_found)) /*search line list */ 

if (lptr == In) /* found the line */ 

{ 

ln_found = 1; 

} 
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else 

{ 



/* skip to next line */ 



ltemp = lptr; 
lptr = lptr->next; 

} 

} 



> 



if ( ! ln_f ound) 

optr = optr->next; /*search next operator's line list */ 



/* unlink the line and free its storage */ 
if (ltemp == lptr) /* delete first line on list */ 

{ 

optr->head = ltemp->next; 
lptr->next = NULL; 
ltemp = NULL; 

if (optr->head == NULL) /* first line was the only line */ 

{ 

optr->tail = NULL; 

} 



else if (lptr == optr->tail) /* delete last line from the list */ 

{ 

ltemp->next = NULL; 
optr->tail = ltemp; 



else /* delete a middle line from the list */ 

{ 

ltemp->next - lptr->next; 
lptr->next = NULL; 

} 

free (lptr) ; 

Optr = NULL; 

} /* end delete_line */ 
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Operator * 

pick_operator (op_list, xpick, ypick) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS : is_op_pick ( ) 

CALLED BY: process_canvas_events ( ) 
process_object () 

PURPOSE: This routine determines if a data stream or output 

line starts on an operator. If so, it returns a pointer to 
that operator. 



Operator_list *op_list; 
int xpick, ypick; 

i 

Operator *ptr; 



/* search operator list */ 

for (ptr = op_list->head; ptr ! = NULL; ptr = ptr->next) 

{ 

if (ptr->optype == OPERATOR) /* skip the null operators */ 

{ 

/* test for pick */ 

if (is_op_pick (ptr->xstart, ptr->ystart, 

ptr->xstop, pt r— >ystop, xpick, ypick) ) 

{ 

return (ptr) ; 

} 

} 

} 

return (NULL) ; 

} /* end pick_operator */ 
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int is_op_pick (xl , yl , x2, y2 , xp, yp) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: pick_operator ( ) 

PURPOSE: This routine determines if a pick has occurred within 
the bounds of an operator. 



int xl, yl, x2, y2, xp, yp; 
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return (1) ; 

else 

return ( 0) ; 



} /* end is_op_pick */ 
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Line * 

pick_line (op_list, xpick, ypick) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: is_line_pick ( ) 

CALLED BY: process_canvas_events ( ) 

PURPOSE: This routine scans each operator's line list checking 
for a line which has been picked. 



Operator_list 

int 



*op_list ; 
xpick, ypick; 



/ 



Operator *optr; 

Line *lptr; 

/* scan the operator list */ 

for (optr = op_list->head; optr != NULL; optr = optr->next) 

{ 

/* scan each line list */ 

for (lptr = optr->head; lptr != NULL; lptr = lptr->next) 

{ 

/* test for pick */ 

if (is_line_pick (lptr->xstart , lptr->ystart, 

lptr->xstop, lptr->ystop, xpick, ypick) ) 

{ 

return (lptr) ; 

} 

} 

} 

return (NULL) ; 



} /* end pick_line */ 
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int is_line_pick (xl, yl, x2, y2, xp, yp) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: pick_line() 

PURPOSE: This routine checks to see if a pick has occurred 
within the pick region of a line. 



int xl, yl, x2, y2, xp, yp; 



< 



/* is (xp,yp) within pick region of a line? */ 
if ( ( (abs (xl-xp) +abs (yl-yp) ) < PROXIMITY) || 

( (abs (x2-xp) +abs (y2-yp) ) < PROXIMITY)) 



return (1) ; 

else 

return (0) ; 



/* end is_line_pick */ 
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append_to_op_list (op_list, op) 

WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: load_proc() 

process_operator () 
process_line ( ) 

PURPOSE: This routine attaches a newly created operator to the 
list of operators. 



Operator_list *op_list; 
Operator *op; 



if (op_list->head == NULL) 

{ 

op_list->head = op; /* attach first operator to list */ 

op_list->tail = op; 



else 

{ 

op_list->tail->next = op; /* attach operator to end of list */ 
op_list->tail = op; 

) 

} /* end append_to_op_list */ 



108 



append_line_to_op (op, In) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: load_proc<) 

process_line () 

PURPOSE: This routine attaches lines which depart an operator to that 
operator's list of output lines. 



Operator *op; 
Line *ln; 



{ 

if (op->head == NULL) 

{ 

op->head = In; /* attach first line to list */ 

op->tail = In; 

) 

else 

{ 

op->tail->next = In; /* attach to end of line list */ 

op->tail = In; 

) 

) /* end append_line_to_op */ 
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Operator * 
alloc_operator ( ) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: create_op() 

PURPOSE: This routine allocates the storage for an operator 
structure . 



Operator *op; 



op = (Operator *) malloc (sizeof (Operator) ) ; 
return (op) ; 



} /* end alloc_operator */ 



Line * 
alloc_line ( ) 

WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: create_line ( ) 

PURPOSE: This routine allocates the storage for a line structure 



{ 

Line 



*ln; 



In = (Line *)malloc (sizeof (Line) ) ; 
return ( In) ; 

} /* end alloc_line */ 
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input_name (item, value, event) 

WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS : is_valid_ada_id ( ) 

display_error_msg ( ) 

CALLED BY: create_name_panel ( ) 

PURPOSE: This routine reads the names from the name panel and 

checks to see if they are valid ada identifier names. If 
they are invalid, an error message is displayed. 



Panel_item 

int 

Event 



item; 
value ; 
'event ; 



***/ 



name_buf = malloc(40); 
name_buf[0] = '\0'; 



/* get storage for the string */ 
/* initialize the storage */ 



/* read the users string from the display */ 
strcpy (name_buf , (char *) panel_get_value (ob ject_name) ) ; 

/* check to see if the name is an ada identifier */ 
if (is_valid_ada_id (name_buf ) ) 

{ 

display_error_msg (1) ; /* blank out the error message area *7 

name;_checked = 1 ; 

) 

else 

{ 

display_error_msg (2 ) ; /* invalid ada id message */ 

) 

/* end input_name */ 
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display_error_msg (msg_id) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: quit_proc() 

process_object () 
input_name ( ) 
input_met ( ) 

PURPOSE: This routine displays error messages on the canvas 

in response to checks made throughout the system. A numeric 
code signifies which message to display. 



int msg_id; 

{ 

char *message; 



message = malloc(45); 
switch (msg_id) 

{ 

case 1 : 

message = " " 

break; 

case 2 : 

message = "SYNTAX ERROR in ADA identifier 
break; 

case 3: 

message = "SYNTAX ERROR in Maximum Execution Time " 

break; 

case 4 : 

message = "ERROR - Either NAME or MET not read 
break; 

case 5: 

message = "ERROR - NAME not read 
break; 

case 6: 

message = "WARNING - The graph has not been stored! " 
break; 

default : 

message = 
break; 

1 

pw_text (canvas_pixwin (drawing_canvas) ,150,15, PIX_SRC, NULL, mess age) ; 

} /* end display_error_msg */ 
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Name * 
get_name ( ) 

WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: process_operator ( ) 
process_line ( ) 

PURPOSE: This routine allocates the storage required for 

a name, stores the name in the structure, and returns a 
pointer to it. 



< 

Name *n; 



n = (Name * ) malloc (sizeof (Name) ) ; 

/* 

strcpy (n->string, name_buf ) ; 

n->length = strlen (n->string) ; 
return (n) ; 

} /* end get_name */ 



/* get storage for the name 
assign the name to this storage 
/* find the name's length 



*/ 

*/ 

*/ 
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display_name (n, otype, xl, yl, x2, y2) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 



CALLED BY: process_operator ( ) 
process_line ( ) 
redraw_diagram ( ) 

PURPOSE: This routine displays the name of an object which 
the user has drawn. 



Name *n; 

int otype, xl, yl, x2, y2 ; 
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{ 

float xcent, ycent; 



/* calc center of the object */ 

xcent = xl + (<x2 - xl) / 2.0); 
ycent = yl + ( (y2 - yl) / 2.0); 

switch (otype) 

f 

case OPERATOR: 

pw_text (canvas_pixwin (drawing_canvas ) , 

(int) xcent- ( (n->length) /2) *8, 

(int) ycent+5,PIX_SRC,NULL,n->st ring) ; 

break; 

case INPUT: 

pw_text (canvas_pixwin (drawing_canvas) ,xl,yl, 

P IX_SRC, NULL, n— >string) ; 

break; 

case OUTPUT: 

pw_text (canvas_pixwin (drawing_canvas ) , x2 , y2 , 

P I X_S RC , NULL, n->string) ; 

break; 

case DATA_STREAM : 

xcent = (x2 - xl) / 2.0; 
ycent = (y2 - yl) / 2.0; 
pw_text (canvas_pixwin (drawing_canvas) , 

xl+ (int) xcent, yl+ (int) ycent, PIX_SRC, 

NULL, n->string) ; 
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break; 



case SELF LOOP : 

pw_text (canvas_pixwin (drawing_canvas) , 
(int) xcent- ( (n->length) / 2) *8, 

(int ) y2-7 , PIX_SRC, NULL, n->string) 

break ; 

default : 



} 



break; 



} /* end display_name */ 
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int 

is_valid_ada_id (name_buf ) 

WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: input_name() 

PURPOSE: This routine checks to see if a name is a legal ada 
identifier 



char name_buf [40] ; 



int space_found = 0; 

int 1 = 1 ; 

if (isalpha (name_buf [ 0] ) ) 

{ 

while (i <= strlen ( (char *)name_buf) - 1) 

{ 

if ( ! isgraph (name_buf [i] ) ) 

{ 

space_found = 1; 
i = i + 1; 

} 

else if ( ( (isalnum (name_buf [i] ) ) | | 

(name_buf [i] ) ) && ! (space_f ound) ) 

{ 

i = i + 1; 

} 

else 

{ 

return (0) ; 

) 

} 

return (1) ; 

} 

else 

{ 

return (0) ; 

} 

} /* end is_valid_ada_id */ 
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input_met (item, value, event) 



WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS : is_valid_met ( ) 

display_error_msg () 

CALLED BY: create_met_panel ( ) 

PURPOSE: This routine reads a MET from the met panel and checks 
to see if it is valid. If it is not, an error message 
is generated. 



Panel_item 

int 

Event 



item; 

value; 

•event; 
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met_buf = malloc(12); 
met_buf[0] = '\0'; 



/* get storage for the met value */ 
/* initialize */ 



/* read in the met string */ 

strcpy (met_buf , (char *)panel_get_value (time_constraint) ) ; 
if ( i s_va 1 i d_me t ( met_bu f ) ) 

{ 

display_error_msg (1) ; /* blank out the message area */ 

met_checked = 1; 



else 

{ 

display_error_msg (3) ; /* invalid met */ 

} 

} /* end input_met */ 
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is valid_met (met_buf ) 



WRITTEN BY: R. K. Thorstenson 



LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: is_valid_met ( ) 

PURPOSE: This routine checks an MET to see if it has the prope 
syntax . 



char met_buf[12]; 



int nondigit_f ound = 0; 

int letter_prev_f ound = 0; 

int mfound = 0; 

int ufound = 0; 

int done =0 ; 

int i = 1 ; 

if (isdigit (met_buf [0] ) ) 

{ 

while (i <= strlen ( (char *)met_buf) - 1) 

{ 

if ( ! isalnum (met_buf [i] ) ) 

{ 

return (0) ; 

} 

else if (isdigit (met_buf [i] )&&! nondigit_f ound) 

{ 

i = i + 1; 

} 

else if (isdigit (met_buf [i] ) ) 

{ 

return (0) ; 

} 

else 



nondigit_f ound = 1; 
switch (met_buf [ i] ) 

{ 

case 'u' : if ( ! letter_prev_f ound) 

{ 

ufound = 1; 

letter_prev_f ound = 1; 



i = i + 1; 

} 

else 

{ 

return (0) ; 

} 

break; 

case 's': if ( ! letter_prev_f ound) 

{ 

letter_prev_found = 1; 
i = i + 1; 

} 

else if ( (uf ound I Imfound) && ! done) 

{ 

done = 1; 
i = i + 1; 

} 

else 

{ 

return (0) ; 

) 

break; 

case 'm' : if ( ! letter_prev_f ound) 

{ 

mfound = 1; 

letter_prev_f ound = 1; 
i = i + 1; 

} 

else 



return (0) ; 

} 

break; 
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default : return(O); 

break; 



) 

if ( (uf ound&& ! done) | | ( ! nondigit_f ound) ) 
return (0) ; 



else 

{ 

return (0) ; 

} 

} /* end is_valid_met */ 
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Met * 
get_met { ) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: process_operator ( ) 
process_line () 

PURPOSE: This routine allocates a storage structure for a 

MET and fills it in with the MET which has been entered. 
It then returns a pointer to this structure. 



Met *tc ; 



/* get storage for the met */ 

tc = (Met *)malloc (sizeof (Met) ) ; 

switch (edit_mode) 

{ 

case OPERATOR: 

/* assign the input string to this storage */ 
strcpy (tc->string,met_buf ) ; 

/* find the length of the string */ 
tc->length = strlen (tc->string) ; 
break; 

case INPUT: 

strcpy (tc->string, "Os") ; 

tc->length = 2; 

break; 

default : 

break; 

} 

return (tc) ; 

} /* end get_met */ 
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display_met (tc, xl , yl , x2, y2) 

WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: process_operator () 
redraw_diagram { ) 

PURPOSE: This routine displays an operator's MET in a position 
centered directly above it. 



Met *tc; 

int xl,yl,x2,y2; 



float xcent; 



xcent = xl + ( (x2 - xl) / 2.0); 
pw_text (canvas_pixwin (drawing_canvas) , 
(int) xcent- ( (tc->length) /2) *8, 

(int) yl-5,PIX_SRC, NULL, tc->string) ; 

) /* end display_met */ 
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Name * 
external ( ) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: process_line ( ) 

PURPOSE: This routine returns the name "EXTERNAL whenever 



it is called. EXTERNAL is the name of the source operator 
for all input lines and the destination of all output 
lines . 




Name *n; 



n = (Name *)malloc(sizeof(Name)); 
strcpy (n->string, "EXTERNAL") ; 
n->length =8; 
return (n) ; 



/* alloc storage */ 
/* assign name */ 
/* assign name */ 



} /* end external */ 
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create PSDLO 




WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: store_proc() 

PURPOSE: This routine creates the PSDL statements represented 

by the user's data flow diagram. A PSDL statement of the 
form 

output_line_name . source_name [ :met] — >destination_name 

will be constructed from the information contained in the 
operator list. 



*«*********************************************************************/ 

{ 

Operator *op__ptr; 

Line *output_ptr; 

char *psdl; 

char *period = 

char * colon = ; 

char ‘arrow = " — >" ; 

f = f open ( "graph . link" , "w" ) ; 
psdl = malloc (150) ; 

op__ptr = op_list->head; /* point at head of the operator list */ 

while (op _jptr != NULL) 

{ 

output_ptr = op__ptr->head; /* pt line ptr at head of line list*/ 
while (output_ptr != NULL) 

{ 

/* assemble the psdl statement by */ 
/* concatenating the parts of the */ 
/* PSDL statements together */ 
psdl = strcat (psdl, output_ptr->name->string) ; 
psdl = strcat (psdl, period) ; 
psdl = strcat (psdl, op_ptr->name->string) ; 

if ( (op_ptr->optype == OPERATOR) && /* put in met for op */ 

(op_ptr->met->string != "Os")) 

{ 

psdl = strcat (psdl, colon) ; 

psdl = strcat (psdl, op__ptr->met->string) ; 

) 

psdl = strcat (psdl, arrow); 
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psdl = strcat (psdl, output_ptr->dest->string) 
fprintf (f , "%s\n", psdl) ; /* store link 

psdl 1 0 ] = ' \ 0 ' ; /* 

output_ptr = output_ptr->next ; 

} 

op__ptr = op__ptr->next ; 

} 

f close (f ) ; 

/* end create_PSDL */ 



stmt in file */ 
reinitialize */ 
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store_diagram( ) 

WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: N/A 

CALLED BY: store_proc() 

PURPOSE: This routine stores the contents of the entire 

storage structure for the diagram in a file named 
graph. pic. It writes out each operator followed 
immediately by the lines which leave it . 



Operator *op_ptr; 

Line *ln_ptr; 

g = f open ("graph .pic", "w" ) ; 

op_ptr = op_list->head; /* start at head of list */ 

while (op_ptr ! = NULL) 

{ 

fprintf (g, "%d\n", op_ptr->optype) ; /* output each node */ 

fprintf (g, "%d\n" , op_ptr->xstart ) ; 

fprintf (g, ”%d\n" , op_ptr->ystart ) ; 

fprintf (g, "%d\n" , op_ptr->xstop) ; 

fprintf (g, "%d\n" , op_ptr->ystop) ; 

fprintf (g, "%s\n", op_ptr->name->string) ; 

fprintf (g, ”%s\n", op_ptr->met->string) ; 

ln_ptr = op_ptr->head; /* start at head of operator's */ 

/* line list */ 

while (ln_ptr != NULL) 

{ /* output line node contents */ 

fprintf (g, "%d\n" , ln_ptr->lntype) ; 
fprintf (g, "%d\n" , ln_ptr->xstart) ; 
fprintf (g, "IdXn", ln_ptr->ystart) ; 
fprintf (g, "%d\n", ln_ptr->xstop) ; 
fprintf (g, ”%d\n", ln_ptr->ystop) ; 
fprintf (g, ”is\n" , ln_ptr->name->string) ; 
fprintf (g, "%s\n", ln_ptr->dest->string) ; 

In ptr = ln_ptr->next ; /* advance to next line */ 

op_ptr = op_ptr->next; /* advance to next operator */ 

) 

f close (g) ; 

) /* end store_diagram */ 



125 



redraw_diagram ( ) 



WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS : draw_ob ject ( ) 
display_name ( ) 
display_met ( ) 
draw_arrowhead ( ) 

CALLED BY: load_j>roc() 

process_canvas_events () 

PURPOSE: This routine blanks out the screen and redraws each object 
stored in the operator list and each operator's line list. 



***********************************************************************/ 

{ 

Operator *op_ptr; 

Line *ln_ptr; 



/* blank the screen 



pw_writebackground (drawing_pw, 0,0, 

window_get (drawing_canvas , CANVAS_WIDTH) , 
window_get (drawing_canvas , CANVAS_HEIGHT) , 
PIX_SRC) ; 

op_ptr = op_list->head; /* start at head of list 



*/ 



*/ 



while (op_ptr != NULL) 

{ 

if (op_ptr->optype == OPERATOR) 

{ /* draw the object */ 

draw_ob ject (op_ptr->optype, op_ptr->xstart , op_ptr->ystart, 
op_ptr->xstop, op_ptr->ystop) ; 
display_name (op_jDtr->name, OPERATOR, op_j3tr->xstart, 

op_ptr->ystart, op_ptr->xstop, op_ptr->ystop) ; 
display_met ( op_pt r->met , op_ptr->xstart, op_ptr->ystart, 
op_ptr->xstop, op_j)tr->ystop) ; 

} 

ln_ptr = op_ptr->head; /* start at head of line list */ 



while (ln_ptr != NULL) 

{ /* draw the line */ 

draw_object (ln_ptr->lntype, ln_ptr->xstart, ln_ptr->ystart, 
ln_ptr->xstop, ln_ptr->ystop) ; 

/* attach its arrowhead */ 

if (ln_ptr->lntype == SELF_LOOP) 

draw_arrowhead (ln_j3tr->xstop, ln_ptr->ystop, 

ln_ptr->xstop, ln_ptr->ystart) ; 



126 



else 



draw_arrowhead(ln_ptr->xstart, ln_ptr->ystart, 
ln_ptr->xstop, ln_ptr->ystop) ; 

display_name (ln_ptr->name, ln_ptr->lntype, ln_ptr->xstart, 
ln_ptr->ystart, ln_ptr->xstop, ln_ptr->ystop) ; 

ln_ptr = ln_ptr->next ; /* adv line pointer */ 

} 

op_ptr = op_ptr->next; /* advance the operator pointer */ 

} 

} /* end redraw diagram */ 
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draw_arrowhead (xl , yl, 



x2, y2 ) 



WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: process_line ( ) 

redraw_diagram ( ) 

PURPOSE: This routine draws an arrowhead at the end of a line at the 
appropriate angle. 



int xl, yl 
{ 

int 

int 

double 



x2 , y2; 



xl_trans, yl_trans, x2_trans, y2_trans; 
xptl, yptl, xpt2 , ypt2, 

xptl_trans, yptl_trans, xpt2_trans, ypt2_trans; 

length, 

theta; 
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/* translate the line to the origin */ 

xl_trans = xl - x2; 
yl_trans = yl - y2 ; 



/* find the length of the line */ 
length = sqrt (pow ( (double) xl_trans, 2 . 0) + 
pow ( (double) yl_trans, 2.0)); 

/* find the angle between the line and the x axis */ 
theta = acos ( (double) xl_trans/length) ; 

/* calculate the coords of the points of the arrowhead */ 
xptl = ARROW_LEN GT H * cos (theta + PI / 6.0); 

yptl = ARROW_LENGTH * sin (theta + PI / 6.0); 

xpt2 = ARROW_LENGTH * cos (theta - PI / 6.0); 

ypt2 = ARROW_LENGTH * sin (theta - PI / 6.0); 

/* reflect y coords across x axis if yl_trans is negative */ 
if (yl_trans < 0) 

{ 

yptl yptl; 

ypt2 — ypt2 ; 

) 

/* translate the arrowhead's coords out to the posit of the line */ 
xptl_trans = xptl + x2; 
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yptl_trans = yptl + y2; 
xpt2_trans = xpt2 + x2; 
ypt2_trans = ypt2 + y2; 



/* draw the point of the arrow 



pw_vector (drawing_pw, 
pw_vector (drawing_pw, 
pw_vector (drawing_pw, 
ypt2_trans. 



xptl_trans, yptl_trans, 
xpt2_trans, ypt2_trans, 
xptl_trans, yptl_trans, 
PIX_SRC, 1) ; 



x2, y2 , PIX_SRC, 1) 
x2 , y2, PIX_SRC, 1) 
xpt2_trans. 



} /* end draw arrow head */ 
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